level thread libraries allow multiple user threads to be implemented on top of LWPs. User threads can be created, destroyed, synchronized and switched between entirely in user space without system calls and switches into kernel mode. This provides a significant performance improvement in thread creation time and context switches. However, there are difficulties in implementing a user level thread scheduler that works well together with the kernel. Scheduler activation While the user threading library will schedule user threads, the kernel will schedule the underlying LWPs. Without coordination between the kernel and the thread library the kernel can make sub-optimal scheduling decisions. Further, it is possible for cases of deadlock to occur when user threads distributed over several LWPs try to acquire the same resources that are used by another user thread that is not currently running. One solution to this problem is scheduler activation. This is a method for the kernel and the thread library to cooperate. The kernel notifies the thread library's scheduler about certain events (such as when a thread is about to block) and the thread library can make a decision on what action to take. The notification call from the kernel is called an "upcall". A user level library has no control over the underlying mechanism, it only receives notifications from the kernel and schedules user threads onto available LWPs, not processors. The kernel's scheduler then decides how to schedule the LWPs onto the processors. This means that LWPs can be seen by the thread library as "virtual processors". Supporting operating systems Solaris has implemented a separate LWP layer since version 2.2. Prior to version 9, Solaris allowed a many-to-many mapping between LWPs and user threads. However, this was retired due to the complexities it introduced and performance improvements to the kernel scheduler. UNIX System V and its modern derivatives IRIX, SCO OpenServer, HP-UX and IBM AIX allow a many-to-many mapping between user threads and LWPs. NetBSD 5.0 introduced a new, scalable 1:1 threading model. Each user thread (pthread) has a kernel thread called a light-weight process (LWP). Inside the kernel, both processes and threads are implemented as LWPs, and are served the same by the scheduler. Implementations Parallel Extensions (Microsoft) GNU Portable Threads Green threads (Java) Light Weight Kernel Threads See also Fiber (computer science) Task (computing) Task parallelism Futures and promises POSIX Threads clone (Linux system call) References External links "The lightweight process pool"