Does sys.dm_os_waiting_tasks include RUNNABLE threads?

Question

From MSDN:

Returns information about the wait queue of tasks that are waiting on some resource.

Is CPU considered a resource in this definition? I initially thought it's not, but what made me concerned is the definition of wait_duration_ms from the same page:

wait_duration_ms Total wait time for this wait type, in milliseconds. This time is inclusive of signal_wait_time.

If it does include RUNNABLE tasks, then what would be the value of wait_type for them? Is it some special value indicating that it's not blocked, but rather waiting for the scheduler, or is it the same value it had when it was in SUSPENDED state?

Answer 1

A task that yields the scheduler because it exhausts its quantum will not appear in sys.dm_os_waiting_tasks; however, any signal wait time it experiences will be accumulated in sys.dm_os_wait_stats under SOS_SCHEDULER_YIELD.

A task that yields to acquire a currently-unavailable "waitable resource" does appear in sys.dm_os_waiting_tasks with the appropriate wait_type and is suspended. It accumulates resource wait time until signalled (when the resource becomes available) and runnable. The task then accumulates signal wait time until it acquires the scheduler and transitions to running status. The task remains visible in sys.dm_os_waiting_tasks until the wait is fully completed (including signal wait), and the wait_type never changes.

That is my understanding, and observation. I could not find this level of detail officially or semi-officially documented anywhere.

A note of caution: sys.dm_os_waiting_tasks is a non-transactional view over rapidly-changing internal SOS task data structures. Many DMVs work in this way, and have been written by different developers at different times. Their output can be very useful, but joining several DMVs can easily lead to apparently inconsistent results.

Comparing snapshots of the sys.dm_os_waits DMV is a better way of splitting aggregate resource and signal waits for a particular wait type. Extended events e.g. scheduling.wait_completed can be used to capture specific wait events if that level of detail is required.

...do you agree the wording of BOL is not correct/confusing?

Technical writing is hard. There'll always be some who complain there is too much detail, while others say there is too little. The DMV shows waits on some resources, until the wait is over. I guess it could be clearer in some respects, but how far can you go without detailing the internal implementation, and ultimately providing the source code?