Chapter 4.2: ThreadsThreading IssuesThreading Issues – fork() and exec()Threading Issues: Thread CancellationSlide 5Slide 6Threading Issues: Signal HandlingSlide 8More – Signal HandlingSlide 10More Signal Handling – for Multi-Threaded ProcessesThread PoolsManagement of Threads - Thread Pools – a ScenarioSlide 14Linux ThreadsLinux – clone()Slide 17End of Chapter 4Chapter 4.2: ThreadsChapter 4.2: Threads4.2Silberschatz, Galvin and Gagne ©2005Operating System ConceptsThreading Issuesto cover:fork() and exec() system callsThread cancellationSignal HandlingThread PoolsLinux threads…4.3Silberschatz, Galvin and Gagne ©2005Operating System ConceptsThreading Issues – fork() and exec()Threading Issues – fork() and exec()In non-threaded systems, forking is rather straightforward – a separate identical process is created.In multi-threaded systems things are implemented differently. In multithreaded system, does the fork() result inDoes the new process duplicates all threads, orIs the new process is single-threaded?As book points out: some versions on Unix duplicate all threads; another duplicates only the thread calling the fork().For the exec() system call, the program specified as the parameter in the exec() system call replaces the entire process, including all threads. Which version of fork() is used?Consider:If exec() is called immediately upon forking, there’s no need to duplicate all threads because the program specified in the parameter to exec() will replace the process. Duplicate only the calling thread.If exec() is not immediately called after forking, the separate process should duplicate all threads.On my system, fork() does not share anything. Upon forking, a completely new image is created identical to the parent, but after the fork(), neither the parent nor the child share anything!4.4Silberschatz, Galvin and Gagne ©2005Operating System ConceptsThreading Issues: Thread CancellationThreading Issues: Thread CancellationWhat happens when a thread is cancelled? What if it has not yet completed its job. This can happen in so many different ways – some of which users cause.Sometimes it is necessary to kill a thread. We know something is wrong or changed our minds about something.Sometimes killing a thread may involve a number of other threads too.What if we halted the loading of a web page with many threads running concurrently? These are important issues and how they are handled impacts much of what is going on in the computing system.4.5Silberschatz, Galvin and Gagne ©2005Operating System ConceptsThreading Issues: Thread CancellationThreading Issues: Thread CancellationCan Cancel threads in two distinct waysAsynchronous cancellation and Deferred cancellation.In Asynchronous cancellation – one thread immediately terminates the target thread (the one to be cancelled).This may / may not be desirable.We have a good choice which is often preferred:Deferred cancellation – the thread to be cancelled checks every so often to see if it should terminate.Thus it can terminate itself gracefully.There are important issues here.Depending on what is executing, we may want a thread to complete its current tasking!4.6Silberschatz, Galvin and Gagne ©2005Operating System ConceptsThreading Issues: Thread CancellationThreading Issues: Thread CancellationConsider the following scenarios:Asynchronous Cancellation: (Immediate Cancellation)Resources have likely been allocated to the target thread.What if the thread is in the middle of updating data or setting flags or communicating with another process? What if other threads are sharing data that ‘this’ thread is accessing and/or updating?Reality is that in asynchronous cancellation, some (but not all) resources may be reclaimed, and this may be a problem.Deferred Cancellation: (Periodic checking, but…)Here, while one thread indicates that a target is to be cancelled, the target thread periodically checks a flag to determine if it should, in fact, terminate itself. These periodic checks are called ‘cancellation points.’Of course, to implement this is a bit more complex in many ways.4.7Silberschatz, Galvin and Gagne ©2005Operating System ConceptsThreading Issues: Signal HandlingThreading Issues: Signal HandlingSignals are used in Unix to tell processes that some particular event has occurred.All operating systems have some sort of signalling mechanism. And Unix is not really any different here….Two approaches to receiving signals, as one might expect:Synchronous or Asynchronous Some signals must be received immediately; others can wait.Frankly, some signals absolutely (for emphasis) must be received and handled immediately.Others definitely (not mitigating their importance) should wait – but not long.4.8Silberschatz, Galvin and Gagne ©2005Operating System ConceptsThreading Issues: Signal HandlingThreading Issues: Signal HandlingSignals have a definite pattern:Signals are generated by occurrence of some eventOnce generated they are passed on to a processThe process must accommodate the required action(s) to take place in response to the signal.We said that signals are received asynchronously and synchronously.Let’s look at some examples – the reason for immediate handling should be clear.4.9Silberschatz, Galvin and Gagne ©2005Operating System ConceptsMore – Signal HandlingSynchronous signal examples: Illegal memory access; division by zero.Your program develops an address and tries to access it; tries to branch out of or reference something outside of your address space…Of course, division by zero is undefined. The process cannot continue unless you’ve got some kind of handler or exception handler to process this event.These are delivered to the process causing the event. (your process?) Hence, these are called, synchronous.Asynchronous signal examples:Brought about by some external event, such as a machine check, operator halt, <control-C>, timer.These signals are normally sent to some ‘other’ process.4.10Silberschatz, Galvin and Gagne ©2005Operating System ConceptsMore – Signal Handling Signals can be handled by default handlers - or user-defined handlers.All signals have default handlers in the kernel.But oftentimes we want to handle our own