Scribd
Upload
37 views14 pages

Aos - W04

1) The document discusses different approaches to implementing threads, including kernel threads managed entirely by the OS and user-level threads managed by a user-level library. 2) With user-level threads, thread operations are much faster since they are simple procedure calls rather than system calls, but blocking system calls affect all threads. 3) To prevent user-level threads from hogging the CPU, the thread library can use a timer interrupt to preempt threads and reschedule other ready threads.

Uploaded by

GES ISLAMIA PATTOKI
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
37 views14 pages

Aos - W04

1) The document discusses different approaches to implementing threads, including kernel threads managed entirely by the OS and user-level threads managed by a user-level library. 2) With user-level threads, thread operations are much faster since they are simple procedure calls rather than system calls, but blocking system calls affect all threads. 3) To prevent user-level threads from hogging the CPU, the thread library can use a timer interrupt to preempt threads and reschedule other ready threads.

Uploaded by

GES ISLAMIA PATTOKI
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 14

Advanced Operating Systems

Dr. Jasim Saeed


The design space

Key
older
MS/DOS UNIXes

address one thread/process one thread/process


space one process many processes

thread
Java OSx, WIN10,
Chorus,
Linux, …
many threads/process many threads/process
one process many processes
Process/thread separation

• Concurrency (multithreading) is useful for:


• handling concurrent events
• building parallel programs
• improving program structure (the Java argument)
• Multithreading is useful even on a uniprocessor
• even though only one thread can run at a time
• Supporting multithreading – that is, separating the concept of a process
(address space, files, etc.) from that of a minimal thread of control
(execution state), is a big win
• creating concurrency does not require creating new processes
• “faster / better / cheaper”
Kernel threads
• OS manages threads and processes
• all thread operations are implemented in the kernel
• OS schedules all of the threads in a system
• if one thread in a process blocks (e.g., on I/O), the OS knows
about it, and can run other threads from that process
• possible to overlap I/O and computation inside a process
• Kernel threads are cheaper than processes
• less state to allocate and initialize
• But, they’re still pretty expensive for fine-grained use (e.g., orders of
magnitude more expensive than a procedure call)
• thread operations are all system calls
• must maintain kernel state for each thread
User-level threads
• To make threads cheap and fast, they need to be implemented at the
user level
• managed entirely by user-level library
• User-level threads are small and fast
• each thread is represented simply by a PC, registers, a stack, and
a small thread control block (TCB)
• creating a thread, switching between threads, and synchronizing
threads are done via procedure calls
• no kernel involvement is necessary!
• user-level thread operations can be 10-100x faster than kernel
threads as a result
User-level thread implementation

• The kernel believes the user-level process is just a


normal process running code
• But, this code includes the thread support library and its associated thread
scheduler
• The thread scheduler determines when a thread runs
• it uses queues to keep track of what threads are doing: run, ready, wait
• just like the OS and processes
• but, implemented at user-level as a library
Kernel threads

MacOS, Win,
Chorus,
address
space Linux, …

os kernel
thread CPU
(thread create, destroy,
signal, wait, etc.)
User-level threads, conceptually
user-level
thread library

(thread create, destroy,


signal, wait, etc.)
MacOS, Win,
Chorus,
address
space Linux, …
?
os kernel
thread CPU
Multiple kernel threads “powering”
each address space
user-level
thread library

(thread create, destroy,


signal, wait, etc.)
MacOS, Win,
Chorus,
address
space Linux, …

kernel threads
os kernel
thread CPU
(kernel thread create, destroy,
signal, wait, etc.)
How to keep a user-level thread from
hogging the CPU?
• Strategy 1: force everyone to cooperate
• a thread willingly gives up the CPU by calling yield()
• yield() calls into the scheduler, which context switches to
another ready thread
• what happens if a thread never calls yield()?

• Strategy 2: use preemption


• scheduler requests that a timer interrupt be delivered by the OS
periodically
• usually delivered as a UNIX signal (man signal)
• signals are just like software interrupts, but delivered to user-
level by the OS instead of delivered to OS by hardware
• at each timer interrupt, scheduler gains control and context
switches as appropriate
Thread context switch
• Very simple for user-level threads:
• save context of currently running thread
• restore context of the next thread
• return as the new thread
• This is all done by assembly language
• it works at the level of the procedure calling convention
• thus, it cannot be implemented using procedure calls
• e.g., a thread might be preempted (and then resumed) in the middle
of a procedure call
What if a thread tries to do I/O?

• The kernel thread “powering” it is lost for the duration of the


(synchronous) I/O operation!
• Could have one kernel thread “powering” each user-level thread
• Could have a limited-size “pool” of kernel threads “powering” all the
user-level threads in the address space
• the kernel will be scheduling these threads, obliviously to
what’s going on at user-level
Pros and Cons of User Level threads

Pros
• Procedure invocation instead of system calls results in fast scheduling
and thus much better performance
• Could run on exisiting OSes that don’t support threads
• Customized scheduling. Useful in many cases e.g. in case of garbage
collection
• Kernel space not required for thread specific data. Scale better for
large number of threads
Pros and Cons of User Level threads
Cons
• Blocking system calls affect all threads
• Similar problem occurs with page faults. The whole process blocks
• Voluntary yield to the run-time system necessary for context switch
• Solution: Run time system may request a clock signal.
• Programs that use multi-threading need to make system calls quite
often. If they don’t then there is usually no need to be multi-threaded.
• Blocking system calls cause no problem
• Page faults can be handled by scheduling another thread from the same
process (if one is ready)
• Cost of system call substantially greater

You might also like