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
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?