1 / 45

Threads

Threads. CS-502 Operating Systems (Slides include materials from Operating System Concepts , 7 th ed., by Silbershatz, Galvin, & Gagne and from Modern Operating Systems , 2 nd ed., by Tanenbaum). Processes – Review. Fundamental abstraction in all operating systems

jnygaard
Télécharger la présentation

Threads

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Threads CS-502 Operating Systems (Slides include materials from Operating System Concepts, 7th ed., by Silbershatz, Galvin, & Gagne and from Modern Operating Systems, 2nd ed., by Tanenbaum) Threads

  2. Processes – Review • Fundamental abstraction in all operating systems • Implementation and management of concurrent activity • Also known as task, job, thread of control, etc. Threads

  3. Processes – Review (continued) • Process state –information maintained by OS for representing process, in PCB • PSW, registers, condition codes, etc. • Memory, files, resources, etc. • Priority, blocking status, etc. • Queues • Ready Queue • Semaphore queues • Other kinds of queues not yet covered (e.g., for disks, communication resources, etc.) Threads

  4. Processes – Review (continued) • Interrupts and traps • Switching contexts • Saving state of one process • Loading state of another process • Scheduling • Deciding which process to run (or serve) next • More later this evening • Interprocess Communication • Later in the course Threads

  5. Processes – Review (continued) • Process creation • Fork + Exec (Unix-Linux) • Create Process (Windows) • Relationships among processes • Parent-child (Unix-Linux) • No default relationship (Windows) • Process termination • Wait for child processes, etc. Threads

  6. Questions? Threads

  7. Problem – Unix/Windows Processes are “heavyweight” • Lots of data in process context • Even more when we study memory management • More than that when we study file systems, etc. • Processor caches a lot of information • Memory Management information • Caches of active pages • Costly context switches and traps • 100’s of microseconds Threads

  8. Problem – Heavyweight Unix/Windows Processes (continued) • Separate processes have separate address spaces • Shared memory is limited or nonexistent • Applications with internal concurrency are difficult • Isolation between independent processes vs. cooperating activities • Fundamentally different goals Threads

  9. Example • Web Server – How to support multiple concurrent requests • One solution: • create several processes that execute in parallel • Use shared memory (shmget()) to map to the same address space in the processes • have the OS schedule them in parallel • Not efficient • space: PCB, page tables, etc. • time: creating OS structures (fork()) and context switch Threads

  10. Example 2 • Transaction processing systems • E.g, airline reservations or bank ATM transactions • 1000’s of transactions per second • Very small computation per transaction • Separate processes per transaction are too costly • Other techniques (e.g., message passing) are much more complex Threads

  11. This problem … • … is partly an artifact of • Unix, Linux, and Windows and of • Big, powerful processors (e.g., Pentium 4) • … tends to occur in most large systems • … is infrequent in small-scale systems • PDAs, cell phones, hand-held games • Closed systems (i.e., controlled applications) Threads

  12. Solution:– Threads • A thread is the execution of a program or procedure within the context of a Unix or Windows process • I.e., a specialization of the concept of process • A thread has its own • Program counter, registers, PSW • Stack • A thread shares • Address space, heap, static data • All other resources with all other threads of the same process Threads

  13. Threads thread 1 stack SP (T1) 0xFFFFFFFF thread 2 stack SP SP (T2) thread 3 stack SP (T3) Virtual address space heap static data 0x00000000 PC code (text) PC (T2) PC (T1) PC (T3) Threads

  14. Single and Multithreaded Processes Threads

  15. Benefits • Responsiveness • Resource Sharing • Economy • Utilization of multi-processor architectures Threads

  16. Threads • Linux, Windows, and various versions of Unix have their own thread interfaces • Similar, not standardized • Some issues • E.g., ERRNO in Unix — a static variable set by system calls • Semantics of fork() and exec() Threads

  17. Who creates and manages threads? • User-level implementation • done with function library (e.g., POSIX) • Runtime system – similar to process management except in user space • Windows NT – fibers: a user-level thread mechanism • Kernel implementation – new system calls and new entity to manage • Linux: lightweight process (LWP) • Windows NT & XP: threads Threads

  18. User Threads • Thread management done by user-level threads library • Three primary thread libraries: • POSIX Pthreads • Win32 threads • Java threads Threads

  19. User Threads (continued) • Can be implemented without kernel support • … or knowledge! • Program links with a runtime system that does thread management • Operation are very efficient (procedure calls) • Space efficient and all in user space (TCB) • Task switching is very fast • Since kernel not aware of threads, there can be scheduling inefficiencies • E.g., blocking I/O calls • Non-concurrency of threads on multiple processors Threads

  20. User Threads (continued) • Thread Dispatcher • Queues in process memory to keep track of threads’ state • Scheduler – non-preemptive • Assume threads are well-behaved • Thread voluntarily gives up CPU by calling yield() – does thread context switch to another thread • Scheduler – preemptive • Assumes threads may not be well-behaved • Scheduler sets timer to create a signal that invokes scheduler • Scheduler can force thread context switch • Increased overhead • Application or thread library must handle all concurrency itself! Threads

  21. Thread Interface • E.g., POSIX pthreads API: • int pthread_create(pthread_t *thread, const pthread_attr_t *attr, void*(*start_routine)(void), void *arg) • creates a new thread of control • new thread begins executing at start_routine • pthread_exit(void *value_ptr) • terminates the calling thread • pthread_join(pthread_t thread, void **value_ptr) • blocks the calling thread until the thread specified terminates • pthread_t pthread_self() • Returns the calling thread's identifier Threads

  22. Kernel Threads • Supported by the Kernel • OS maintains data structures for thread state and does all of the work of thread implementation. • Examples • Windows XP/2000 • Solaris • Linux • Tru64 UNIX • Mac OS X Threads

  23. Kernel Threads (continued) • OS schedules threads instead of processes • Benefits • Overlap I/O and computing in a process • Creation is cheaper than processes • Context switch can be faster than processes • Negatives • System calls (high overhead) for operations • Additional OS data space for each thread Threads

  24. Threads – supported by processor • E.g., Pentium 4 with Hyperthreading™ • www.intel.com/products/ht/hyperthreading_more.htm • Multiple CPU’s on a single chip • True concurrent execution within a single process • Requires kernel support • Re-opens old issues • Deadlock detection • Critical section management of synchronization primitives Threads

  25. Unix Processes vs. Threads • On a 700 Mhz Pentium running Linux • Processes: • fork()/exit(): 250 microsec • Kernel threads: • pthread_create()/pthread_join(): 90 microsec • User-level threads: • pthread_create()/pthread_join(): 5 microsec Threads

  26. Models for Implementation • Many-to-One • One-to-One • Many-to-Many Threads

  27. Many-to-One • Many user-level threads mapped to single kernel thread • Examples: • Solaris Green Threads • GNU Portable Threads Threads

  28. Many-to-One Model Threads

  29. One-to-One • Each user-level thread maps to kernel thread • Examples • Windows NT/XP/2000 • Linux • Solaris 9 and later Threads

  30. One-to-one Model Threads

  31. Many-to-Many Model • Allows many user level threads to be mapped to many kernel threads • Allows the operating system to create a sufficient number of kernel threads • Solaris prior to version 9 • Windows NT/2000 with the ThreadFiber package Threads

  32. Many-to-Many Model Threads

  33. Two-level Model • Similar to M:M, except that it allows a user thread to be bound to kernel thread • Examples • IRIX • HP-UX • Tru64 UNIX • Solaris 8 and earlier Threads

  34. Two-level Model Threads

  35. Threading Issues • Semantics of fork() and exec() system calls for processes • Thread cancellation • Signal handling • Thread pools • Thread specific data • Scheduler activations Threads

  36. Semantics of fork() and exec() • Does fork() duplicate only the calling thread or all threads? • Easy if user-level threads • Not so easy with kernel-level threads • Linux has special clone() operation • Windows XP has something similar Threads

  37. Thread Cancellation • Terminating a thread before it has finished • Two general approaches: • Asynchronous cancellation terminates the target thread immediately • Deferred cancellation allows the target thread to periodically check if it should be cancelled Threads

  38. Signal Handling • Signals are used in UNIX systems to notify a process that a particular event has occurred • A signal handler is used to process signals • Signal is generated by particular event • Signal is delivered to a process • Signal is handled • Options: • Deliver the signal to the thread to which the signal applies • Deliver the signal to every thread in the process • Deliver the signal to certain threads in the process • Assign a specific thread to receive all signals for the process Threads

  39. Thread Pools • Create a number of threads in a pool where they await work • Advantages: • Usually slightly faster to service a request with an existing thread than create a new thread • Allows the number of threads in the application(s) to be bound to the size of the pool Threads

  40. Thread Specific Data • Allows each thread to have its own copy of data • Useful when you do not have control over the thread creation process (i.e., when using a thread pool) Threads

  41. Scheduler Activations • Both M:M and Two-level models require communication to maintain the appropriate number of kernel threads allocated to the application • Scheduler activations provide upcalls – a communication mechanism from the kernel to the thread library • This communication allows an application to maintain the correct number kernel threads Threads

  42. Mutual Exclusion within Threads externvoid thread_yield(); externint TestAndSet(int &i); /* sets the value of i to 1 and returns the previous value of i. */ void enter_critical_region(int &lock) { while (TestAndSet(lock) == 1) thread_yield(); /* give up processor */ }; void leave_critical_region(int &lock) { lock = 0; }; Threads

  43. Threads inside the OS kernel • Kernels have evolved into large, multi-threaded programs. • Lots of concurrent activity • Multiple devices operating at one time • Multiple application activities at one time • A useful tool • Special kernel thread packages, synchronization primitives, etc. • Useful for complex OS environments Threads

  44. Threads – Summary • Processes are very heavyweight in Unix, Linux, Windows, etc. • Need for isolation between processes at odds with desire for concurrency within processes • Threads provide an efficient alternative Thread implementation and management strategies depend upon expected usage • Kernel support or not • Processor support or not Threads

  45. Break Next topic Threads

More Related