Skip to content

Commit 0c1cfed

Browse files
authored
Merge pull request #15772 from pmasl/patch-833
Update thread-and-task-architecture-guide.md
2 parents 3c76978 + 73b6d18 commit 0c1cfed

1 file changed

Lines changed: 3 additions & 3 deletions

File tree

docs/relational-databases/thread-and-task-architecture-guide.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -41,9 +41,9 @@ A [!INCLUDE[ssNoVersion](../includes/ssnoversion-md.md)] **worker thread**, also
4141
A **scheduler**, also known as SOS scheduler, manages worker threads that require processing time to carry out work on behalf of tasks. Each scheduler is mapped to an individual processor (CPU). The time a worker can remain active in a scheduler is called the OS quantum, with a maximum of 4 ms. After its quantum time expires, a worker yields its time to other workers that need to access CPU resources, and changes its state. This cooperation between workers to maximize access to CPU resources is called **cooperative scheduling**, also known as non-preemptive scheduling. In turn, the change in worker state is propagated to the task associated with that worker, and to the request associated with the task. For more information about worker states, see [sys.dm_os_workers](../relational-databases/system-dynamic-management-views/sys-dm-os-workers-transact-sql.md). For more information about schedulers, see [sys.dm_os_schedulers ](../relational-databases/system-dynamic-management-views/sys-dm-os-schedulers-transact-sql.md).
4242

4343
> [!NOTE]
44-
> Imagine an application sends a query (request) to a [!INCLUDE[ssde_md](../includes/ssde_md.md)] that's configured with MAXDOP 32, and CPU Affinity is configured for 8 CPUs (schedulers). The query plan has a join between two tables, with a total of 3 query plan operators. Each of the operators is executed in parallel, and spawns 32 tasks (the MAXDOP limit) plus a coordinating task.
45-
> At any given time, the request has at least 99 tasks. Each task will be assigned to a worker, and when a worker assigned to a task gets active scheduler time (its quantum time), the task will be in the RUNNING state.
46-
> Because there are only 8 schedulers, only 8 workers can be active at any given point. A worker can only remain active for the duration of its quantum (4ms) and must yield its scheduler after that quantum has elapsed, so that a worker assigned to another task may become active. When a worker's quantum expires and is no longer active, the respective task is placed in a FIFO queue in a RUNNABLE state, until it moves to a RUNNING state again (assuming the task won't require access to resources that are not available at the moment, such as a latch or lock, in which case the task would be placed in a SUSPENDED state instead of RUNNABLE, until such time those resources are available).
44+
> Imagine an application sends a query (request) to a [!INCLUDE[ssde_md](../includes/ssde_md.md)] that's configured with MAXDOP 8, and CPU Affinity is configured for 32 CPUs (schedulers). The query plan has a join between two tables, with a total of 3 query plan operators. Each of the operators is executed in parallel, and spawns 8 tasks (the MAXDOP limit) plus a coordinating task.
45+
> At any given time, the request has at least 27 tasks. Each task will be assigned to a worker, and when a worker assigned to a task gets active scheduler time (its quantum time), the task will be in the RUNNING state.
46+
> Because there are 32 schedulers, up to 27 workers can be active at any given point for this request. A worker can only remain active for the duration of its quantum (4ms) and must yield its scheduler after that quantum has elapsed, so that a worker assigned to another task may become active. When a worker's quantum expires and is no longer active, the respective task is placed in a FIFO queue in a RUNNABLE state, until it moves to a RUNNING state again (assuming the task won't require access to resources that are not available at the moment, such as a latch or lock, in which case the task would be placed in a SUSPENDED state instead of RUNNABLE, until such time those resources are available).
4747
> This means that during a parallel query execution, a single request can spawn multiple tasks, and each task is assigned to a worker, up to the MAXDOP limit.
4848
4949
### Allocating threads to a CPU

0 commit comments

Comments
 (0)