Version Differences for Lock For Workflow

Select 'Yes' to lock the agent and working directory for the duration of this workflow starting at the execution of this job. Locking for the workflow allows jobs after this one to reuse the agent and working directory. Locking for the workflow will prevent other workflows from stepping on your working directory.

----

'''Setting ''Lock For Workflow'' should be avoided when using iterations, as locks may be left over. It is recommended to instead set for ''Lock for Job'' and then use a unique working directory for each iteration!'''

+

'''Technical Description:'''

+

When a job in a workflow tries to schedule itself for agent+workdir selection. The comparison with existing workflow level locks is not atomic with the request for new locks. This means that if multiple jobs are trying to acquire a resource "for workflow" in at the same time, there is a risk that they may both end up trying to acquire the same resource exclusively and will not release it; resulting in the workflow deadlocking.

+

'''Mitigation:'''

+

If there is a need to do have parallel work done on the same [agent+workdir] by multiple jobs (iteration or regular parallel configuration), create a new single job which will run prior to these which just locks that desired [agent+workdir] combination "for workflow". This configuration order guarantees the subsequent jobs will detect that the resource is already bound to the workflow and not try to reacquire it themselves.

 Select 'Yes' to lock the agent and working directory for the duration of this workflow starting at the execution of this job. Locking for the workflow allows jobs after this one to reuse the agent and working directory. Locking for the workflow will prevent other workflows from stepping on your working directory.
 ----
 '''Setting ''Lock For Workflow'' should be avoided when using iterations, as locks may be left over.  It is recommended to instead set for ''Lock for Job'' and then use a unique working directory for each iteration!'''
                 '''Technical Description:'''
                 When a job in a workflow tries to schedule itself for agent+workdir selection.  The comparison with existing workflow level locks is not atomic with the request for new locks. This means that if multiple jobs are trying to acquire a resource "for workflow" in at the same time, there is a risk that they may both end up trying to acquire the same resource exclusively and will not release it; resulting in the workflow deadlocking.
                 '''Mitigation:'''
                 If there is a need to do have parallel work done on the same [agent+workdir] by multiple jobs (iteration or regular parallel configuration), create a new single job which will run prior to these which just locks that desired [agent+workdir] combination "for workflow".  This configuration order guarantees the subsequent jobs will detect that the resource is already bound to the workflow and not try to reacquire it themselves.