Threading: running steps in parallel

Threading enables steps to run in parallel, either on the same server or on different servers. Threading is controlled by the Thread property setting for a step. By default, the Thread property is set to No. Threading helps reduce project execution time when there are parts of a project that can be run independently of each other.

When the Thread property for multiple adjacent steps is set to Yes, the system attempts to run the step in parallel. Such steps are considered thread-enabled, and each step can be run separately while the rest of the job continues. Threading follows these rules.

• At least two steps in sequence must have the Thread property set to Yes for threading to occur. A set of threaded steps in sequence is called a thread block. Thread blocks can continue into steps that are part of an Inline. For example, if a step in a project contains an Inline and the first step of that Inline is also threaded, the two steps are part of the same thread block. They run concurrently. The thread block follows threaded steps, including nested Inline steps, until a Join step or a nonthreaded step is encountered. Take care to avoid race conditions when using nested Inline steps. A race condition can be caused by an inlined threaded step depending on results or data from the threaded parent step.
• A thread block is terminated by a step whose Thread property is set to Join or when it encounters a nonthreaded step. At that point step execution becomes sequential again.
• When the system encounters a thread-enabled step, it attempts to start the step. If the following step is also threaded, the system attempts to start that step and continues on to the next step, repeating until there are no more thread-enabled steps or the job limit is reached. If the selector for the project specifies a server pool, the job limit conceptually is the sum of the job limits of servers in the pool.
  Note: The start time of a threaded steps depends on the availability of the server it is supposed to run on. If a step cannot be started, the system waits and tries again. You cannot explicitly control which steps start first.
• Steps may end up running simultaneously on one server (depending on the capacity of that server) or on several servers, depending on how many servers match the selector.
• To force all steps to run on a single server, use the Sticky property for the project.
• If there are multiple thread blocks, the first thread block must complete before the next thread block can start.

  In the following example, steps 2, 3, and 4 must complete before steps 5 and 6 can start.

  Project	Thread property for step
  Step 1	No
  Step 2	Yes
  Step 3	Yes
  Step 4	Join
  Step 5	Yes
  Step 6	Yes
  Step 7	No

• Use the Max Threads property for the project to limit the number of threads that can run at the same time. Each thread-enabled step and its inline project, if any, can result in parallel processes. All processes are counted until the maximum for the parent project is reached. The system stops launching new parallel processes when it reaches the Max Threads value. It waits until the number of parallel processes for the project drops below the Max Threads value before continuing.