Multithreading models

•There are three dominant models for thread libraries, each with its own trade-offs
–many threads on one LWP (many-to-one)
–one thread per LWP (one-to-one)
–many threads on many LWPs (many-to-many)
•Similar models can apply on scheduling kernel threads to real CPUs
Many-to-one
=> Many user-level threads mapped to single kernel thread

•In this model, the library maps all threads to a single lightweight process•Advantages:

–totally portable
–easy to do with few systems dependencies

•Disadvantages:

–cannot take advantage of parallelism

–may have to block for synchronous I/O

–there is a clever technique for avoiding it

•Mainly used in language systems, portable libraries
One-to-one

=>Many user-level threads mapped to single kernel thread

•In this model, the library maps each thread to a different lightweight process

•Advantages:

–can exploit parallelism, blocking system calls

•Disadvantages:–thread creation involves LWP creation

–each thread takes up kernel resources

–limiting the number of total threads

•Used in LinuxThreads and other systems where LWP creation is not too expensive

Many-to-many => Allows many user level threads to be mapped to many kernel threads
=> Allows the operating system to create a sufficient number of kernel threads

•In this model, the library has two kinds of threads: bound and unbound

–bound threads are mapped each to a single lightweight process

–unbound threads may be mapped to the same LWP

•Probably the best of both worlds

•Used in the Solaris implementation of Pthreads (and several other Unix implementations)