Control Build Concurrency with Resources

As explained in Working with Resources section, one can define resources in grid page to control how many steps can run concurrently. Specifically, if resource requirement is applied to master step, the whole build will be queued when the requirement is not satisfied. You may also refer to the resource management tutorial on how to control the build concurrency.

Concurrency of Builds of the Same Configuration

Concurrency of builds of the same configuration is also affected by workspaces. QuickBuild guarantees that a workspace is only used by one build at a time. Assume that step1 and step2 belongs to build1 and build2 respectively. If step1 and step2 both matches the single same node, the second step will wait until the first step finishes. Specifically if the waiting step is of master step, the whole build will be put into queue for waiting.

Possible Deadlocks

Deadlock is possible if a child step requires a resource which has already been acquired by parent step. Taking the One Build For One Agent example, if the child step test of child project1 also requires resource Agent, deadlock will happen if there is only one agent available. In this case:

1. master step has already acquired resource Agent.
2. master step will not finish unless child step test starts and finishes.
3. child step test will not start unless it can get a free Agent resource.
4. resource Agent will not be free unless master step finishes.

This makes the system enters into a infinite waiting loop unless there is another free Agent resource is available. Considering there might be many builds running in the system concurrently, deadlock can happen regardless how many resource you configured in the system.

To avoid such deadlock is simple: never try to acquire the same resource multiple times in the same build.

Another deadlock possibility is caused by looped waiting of different resources. Assume that:

1. we have two resources in the system: resource1 and resource2.
2. master step of build1 (assume master1) requires resource1 and its child step child1 requires resource2.
3. master step of build2 (assume master2) requires resource2 and its child step child2 requires resource1.

Deadlock may happen if there is only one resource1 and resource2 and if we run build1 and build2 at the same time:

1. master1 acquires resource1.
2. master2 acquires resource2.
3. master1 will not finish unless child1 starts and finishes.
4. master2 will not finish unless child2 starts and finishes.
5. child1 will not start unless resource2 is released by master2.
6. child2 will not start unless resource1 is released by master1.

Even if there are multiple resource1 and resource2 configured in the system, deadlock can still happen if many builds of this type are running together. To avoid such deadlock, you should avoid looped waiting of different resources. If resource1 waits for resource2 in a build setup, you should be careful that other build setups will never cause resource2 to wait for resource1. This also holds true if three or more resources are involved.