Update thread-and-task-architecture-guide.md

Author: pmasl

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

@@ -43,7 +43,7 @@ A **scheduler**, also known as SOS scheduler, manages worker threads that requir
 > [!NOTE]
 > 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.    
 > 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.   
-> Because there are only 8 schedulers, and any worker can only remain active for the duration of its quantum (4ms), a worker 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).
+> 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).
 > 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. 
 
 ### Allocating threads to a CPU