SOS_SYNC_TASK_ENQUEUE_EVENT is recorded when a task is started synchronously: the starting thread enqueues the task on an SOS node and waits for it to actually begin running (or for the enqueue to time out). Most task starts in SQL Server are asynchronous, control returns immediately once the request is queued, so the synchronous variant is the exception, used where the starter genuinely must know the task is under way.
The wait is the starter standing at the door until the new task steps through it.
Is It a Problem?
No; it has not been a contention point, and synchronous task starts are rare enough that totals stay negligible. In a heavily saturated scheduler situation the enqueue-to-start gap could theoretically stretch, but that scenario announces itself through THREADPOOL and runnable-queue evidence long before this wait becomes informative.
Filter it.
Common Causes
- Internal operations that start their worker tasks synchronously.
What To Do
- Filter it out of wait analysis.
- Worker starvation questions belong to
THREADPOOLandsys.dm_os_schedulers, not here.
How To See It
Rank waits with Get-WaitStatistics; expect near-zero.
Part of the SQL Server Wait Types Library.
Related deep dive: SOS_SCHEDULER_YIELD Wait Type.
Leave a Reply