Why some SQL Server components do not work or are not supported when SQL Server is in lightweight pooling mode

Lightweight pooling mode, also known as fiber mode, uses Windows fibers to service User Mode Scheduler (UMS) workers rather than threads.  Windows fibers are lighter weight execution mechanisms than threads, with one thread typically hosting multiple fibers.  Because the base execution facility in Windows is still the thread, you are still running code via a thread when in fiber mode, it’s just that context switches between threads occur far less, and expensive switches to kernel-mode occur less frequently, because fibers are user-mode constructs that the kernel knows nothing of.  Context switches can occur between multiple fibers hosted by a given thread rather than between threads, and some operations that would normally require a switch into kernel-mode can instead be carried out entirely in user-mode.  Using fibers effectively teaches threads to juggle.


The reason certain SQL Server components aren’t supported or do not work reliably when in fiber mode is that they make use of thread-specific facilities such as Thread Local Storage (TLS).  As the name implies, TLS is data storage that is private to a given thread.  Because multiple UMS workers may share a given thread when in fiber mode, the TLS changes one worker makes may inadvertently affect other workers.  If the component in question is supported at all in fiber mode, it may behave erratically, especially when the system is under load.


Another way in which a fiber can make use of thread-specific facilities is to create kernel objects or critical sections.  Kernel objects and critical sections are owned by threads.  If a fiber-based UMS worker makes an ODS call (for example, an xproc making srv_* calls) after taking ownership of a kernel object or critical section, the worker can actually end up on a different thread when it returns from the call.  This would orphan the kernel object or critical section, potentially resulting in the next worker that attempts to acquire it hanging.  If enough of these workers hang waiting on orphaned objects, your SQL Server may appear to be hung.


You may be familiar with the concept of thread safety in multi-threaded programming.  Certain SQL Server components are not supported or do not work reliably in fiber mode because they are not “fiber safe.”  The same types of issues that afflict multi-threaded applications that are not thread safe affect them as well, only at the fiber level rather than at the thread level.


Skip to main content