On Windows and Linux, workers are implemented using lightweight threads known as fibers. An implementation utilizing fibers allows workers to be scheduled amongst themselves co-operatively, rather than being scheduled preemptively by the operating system thread scheduler. The result is that a context switch between fibers can be more finely controlled. The database kernel schedules the fibers to maximize processor affinity and tightly control the execution priority of each worker.

Because fibers do not rely on the operating system scheduler, a fiber must explicitly yield control to another fiber when it is waiting for some other activity to complete. For example, if a task that is executing on a fiber needs to block while waiting for an I/O operation to complete, it relinquishes control to another fiber. The thread hosting the original fiber is free to pick up another fiber immediately and begin its execution without a kernel context switch. If a fiber blocks and does not yield control, it blocks the thread that is hosting it and prevents other fibers from running on that thread. If more than one thread is hosting fibers, only the thread that is hosting the waiting fiber is blocked: other threads are still free to run fibers.

On Windows and Linux platforms there are at least as many fibers created as required by the maximum concurrency setting of the database server, as specified by the -gnh option. The database server utilizes a subset of these fibers during server execution, corresponding to the current server multiprogramming level. For each fiber the operating system must reserve address space for its stack. The amount of stack required for each fiber depends on the setting of the -gss server option. See -gss dbeng12/dbsrv12 server option.

The amount of address space required by a network server for execution stacks is proportional to the maximum multiprogramming level. See -gn dbsrv12 server option.