Day 10Threads

Threads and Processes

Process is seen as two entities Unit of resource allocation (process or

task) Unit of dispatch or scheduling (thread

or lightweight process)

What is a thread?

A thread is a unit of dispatching within a process.

A thread has a kernel stack, user stack and a TCB. The TCB implies that it has its own copy of the

PC, GP registers and state i.e. running, not running.

It also has a per thread static storage for local variables.

A thread has access to memory and resources of its process shared by all threads in the process.

Threads in modern operating systems

Single-threading - Only 1 process(DOS) or 1 thread per process (flavors of UNIX).

Multi-threading - More than 1 thread in 1 process and many processes - Solaris, W2K, LINUX.

Why threads?

Less time to create a thread. Less time to delete a thread. Switching between threads of the same process is

faster as user address space need not be restored.

Communication is more efficient as they share the address space and don't need to invoke the kernel for message passing.

On multi-processor systems, threads can be scheduled on different processors and increase efficiency.

All resources of the process are available to the child thread. e.g. same file pointer

Thread examples

Web server Word processor

Figure 4.2 Thread life cycle. [Deitel et al]

4.4 Thread States: Life Cycle of a Thread

Common Thread operations

create, exit join - When a process is created a primary

thread is created. If the primary thread returns, the process

terminates. In order to make the process wait for

secondary threads to finish, the primary thread is put to sleep until the secondary thread completes.

The primary thread is said to JOIN each of the thread it creates.

When a thread T1 joins T2, T1 does not execute until T2 terminates.

POSIX threads

Portable Operating Systems Interface for Computing Environments. – Is an IEEE standard.

provides a standard interface between threads and the library.

Not concerned with the details of the implementation – can be implemented at the OS level or at the application level.

Functions: Sleep(seconds) – puts the entire process to sleep.

Use pthread_delay_np to make thread sleep. exit() – causes the entire process to quit.

Use pthread_exit to make thread quit. pthread_self() – id of the current thread pthread_setsched_parama() – to voluntarily yield the scheduler

Solaris threads are defined in thread.h while pthreads are defined in pthread.h

Use “-lpthread” to compile programs that includes functions from the pthread library.

User level threads and kernel level threads

User level threads (Many to one mapping)

Implement thread creation/manipulation using procedure calls to a user-level library rather than system calls. ULTs can run on any OS, as long as the thread library is

available. The thread management is done by the application and the

kernel is unaware of threads. Allows the user to use scheduling algorithms that are

more appropriate to the application. Switching between threads is done without invoking the

kernel and the only context that needs to be saved is the program counter, user registers and stack pointers.(Threads voluntarily give up the CPU).

User level threads (Many to one mapping)

OS is unaware of the threads and schedules independent of number of threads per process.

A process with many threads is not going to be assigned a larger time-slice to run than a process with fewer threads

If the application does require system calls, then when a thread gets blocked, process itself gets blocked.

In a multi-processing environment, the kernel cannot schedule different threads of a process on different processors as it is unaware of the threads.

Kernel-level threads (KLT) (One to one mapping)

OS is aware of all the threads. Switch between threads requires a mode switch - still

inexpensive as the context is still small - more expensive than ULT as mode switch required.

OS schedules the threads and hence if a thread blocks a process need not block.

Can be efficiently used in a multi-processing environment.

Kernel-level threads (KLT) (One to one mapping)

Less portable as the code has to be re-written to use the API of the under-lying OS.

Use of POSIX threads reduces this problem. A lot of overhead on the OS as a process may have

100s of threads and this would result in thousands of dispatch units for the OS to manage.

Linux supports the one-to-one i.e. KLT model. Efficient mode(context) switching mechanism is available.

Combined approach (many to many or m-to-n approach)

Windows XP and old versions of Solaris A process may have a number of ULTs

and these can be mapped to smaller number or equal number of KLTs.

By allowing the mapping, we can reduce the number of threads the OS sees. The programmer can select which threads

(blocking threads) are seen by the kernel separate from the non-blocking.

Creation, synchronization etc. are done at the application level.

If one were to generalize,

It could be said that ULTs results in a much faster execution

time than KLTS which are much faster than processes.

Also, use ULTs for CPU-bound operations i.e.

not requiring too many system calls. Use KLTs for I/O bound processes and

in cases where multi-processing can be taken advantage of.

Support for threads

A number of languages now support multi-threading. Initially, it was only Ada. But, Ada was used

primarily in military applications. Java, C#, Python, Visual C++ .NET and Visual

BASIC .NET all currently support multi-threading. C and C++ traditionally did not. But, now

include special libraries. Most OS support multi-threading.

Win-32 threads, C-thread(Mach) and POSIX threads, Solaris threads.

POSIX specifies the Pthread standard. Allows portable code and is supported by Solaris, LINUX and Windows XP.

References

Listed textbook (Stallings, 6th edition)

Deitel, Deitel and Choffnes, “Operating Systems,” 3rd edition, Prentice Hall.