Chapter 6 (6.7 & 6.9 only) - Threads & Mutex

1. Chapter 6 (6.7 & 6.9 only) - Threads & Mutex • Threads • A Thread is a basic unit of CPU utilization consisting of a program counter, register set and stack space. • Remaining resources (memory space and operating system resources, such as open files) are shared with peer threads within the same process. • A thread is a lightweight process.

2. By sharing a single process’ memory space and O/S objects a program written with multiple threads requires less overhead at context switch time. This can lead to more efficient use of the CPU for multi-threaded applications. • Figure 6.10: Example of two multi-threaded processes. • Threads can execute the same code with different contexts (different register sets, stack & program counter). • A process has at least one thread.

3. Extend SOS to support threads through three new calls: • int CreateThread(char *startAddr, char *startStack) - start a new thread; code begins at startAddr and the stack it will use is at startStack. Call returns a Thread ID (tid). • int ExitThread(int returnCode) - similar to a process Exit() call, except the last thread of a process, where it is exactly the process Exit() call. • int WaitThread(int tid) - block the calling thread until the thread specified by tid calls ExitThread(). • Stack management is the responsibility of the thread creator (except for the first thread).

4. Advantages of Threads • Provide parallel (possibly pseudo-parallel) programming. • Cheaper to create and destroy. • Cheaper to context switch between. • By definition they share memory, meaning shared-memory based IPC is a natural and slow system calls are not needed to communicate. • Good for parallel algorithms that are tightly coupled and that use the same data structures. • Common term: multi-threaded server.

5. Uses of threads • Partition the activities of a single process (Figure 6.11). • Permit asynchronous I/O within a process -- have a thread wait for the I/O to complete. • Activity replication -- a server process can create threads on demand as services are requested. Great example - a multi-thread web server. Another example: disk block server (Figure 6.12). • Thread implementation (6.7.5): not covered.

6. Process - has its own address space and is allocated CPU time. • Process with threads - split out the concept of CPU allocation into the thread, leaving the process as a shell to hold everything else. • Threads can be implemented in the operating system or they can be implemented totally within a user process (called user threads). • A user process does not need to be in system mode and use special instructions to swap stack pointers and register sets. A timer helps, though. • User threads are more efficient (no O/S switch).

7. A process running user threads may run more efficiently but can’t take advantage of any O/S thread calls, since the O/S isn’t aware of the user-level threads. • Kernel threads are threads designed to run within the O/S itself. • Examples of Threads: • O/S-level threads are built into Mach, Solaris, OS/2, Windows NT & most modern UNIXes. • User-level threads can be found all over. Of note -- the Java language runtime supports threads. By extension this means Java-aware browsers also implement user-level threads (Netscape, MSIE, etc.).

8. Java Threads (taken from chapter 15 of The Java Tutorial). • JavaSOS uses Java threads, so it’s worth covering their specifics. • Java thread definition: a single sequential flow of control within a program. • The Thread class is provided in the java.lang package. • You can either extend the Thread class or in the case of a class already being extended (like the Applet class) you can say the class implements Runnable. • Either way you can then override a number of Thread class methods that affect thread behavior.

9. Example using extends: class SimpleThread extends Thread { public SimpleThread(String str) { super(str); } public void run() { for (int i = 0; i < 10; i++) { System.out.println(i + “ “ + getName()); try { sleep((int) (Math.random() * 1000)); } catch (InterruptedException e) {} } System.out.println(“DONE! “ + getName()); } }

10. Example creating two instances of SimpleClass and running them: class TwoThreadsTest { public static void main (String[] args) { new SimpleThread(“Jamacia”).start(); new SimpleThread(“Fiji”).start(); } } • Notice use of overridden Thread method run().

11. Example using implements: Class Clock extends Applet implements Runnable { public void start() { if (clockThread == null) { // if applet just loaded clockThread = new Thread(this, “Clock”); clockThread.start(); } } public void stop() { clockThread = null; } public void run { while (Thread.currentThread() == clockThread) { repaint(); // (sleep w/ exception handling) // } }

12. JavaSOS uses implements Runnable for the Java threads. Check these files: AppGUICounter.java, AppTests.java - the three user-level applications are all Java threads. HWSimulation.java:class HWSimulatedDisk HWSimulation.java:class HWTimer SOSStart.java:class SOSStart • JavaSOS uses the suspend() and resume() methods of the Thread class to block one process and start another one running.

13. Implementation of Mutual Exclusion • Two prior solutions to the mutex problem: use of Message Queues & that pesky ExchangeWord() (more on this later). • 1st solution - disable interrupts while the process is in a critical section (no interrupts == no timer interrupt == no context switch to some other process). Book mentions it works well on a single-processor machine, but neglects the downside of having a user program running with interrupts disabled! • 2nd solution - Use ExchangeWord(): a special hardware instruction that allows one processor to read and modify a word in memory without any other processor getting access (atomic read & modify).

14. Implementation of Mutual Exclusion • Good for multiprocessor mutex solutions; exists in different forms, such as “Test and Set”. • Software Solutions - no special hardware instructions exist to enforce the mutex. • First solution by Dekker in 1965; complex. • A simpler solution done by Peterson in 1981. Imagine two processes, each with the same structure: void Processn(void) { while (1) { DoSomeStuff(); EnterCriticalSection(0); DoCriticalSectionStuff(); LeaveCriticalSection(0); } }

15. To work, the processes have to agree that: • A process will not wait forever in EnterCriticalSection(). • Only one process at a time can be in the critical section. • A process will spend a finite time in the critical section. • A process that wants to enter its critical section cannot be made to wait for the other process to enter its critical section. enum { False = 0; True = 1; }; int interested[2] = {False, False}; int turn = 0; void EnterCriticalSection(int this_process) { int other_process = 1 - this_process; interested[this_process] = True; turn = this_process; while (turn == this_process && interested[other_process]) { // do nothing (busy loop) } }

16. void LeaveCriticalSection(int this_process) { interested[this_process] = False; } • This algorithm works with two processes contending for the critical section and it also works if there’s only one process. • It’s important you understand how this code works!

17. Disabling Interrupts • Fast! • No busy waiting! • Uniprocessor-only solution! • Best solution for a single processor (with the exception you don’t want the interrupts to be disable-able within user mode). • Using ExchangeWord() • Busy waiting :( • Requires hardware assistance (memory subsystem) :( • Works with multiple processors! • Best solution for shared memory multiprocessors. • Peterson’s algorithm (software-only solution) • Busy waiting :( • No hardware assistance required! • Works with multiple processors! • Best solution for distributed systems with no centralized control.