Download Operating Systems CS 414: Threads and Message Passing - Prof. Sang Son and more Study notes Operating Systems in PDF only on Docsity!
CS 414 : Operating Systems
UNIVERSITY OF VIRGINIA
Department of Computer Science
Fall 2005
Topic 7: Threads and Messages
Threads Each process has a) PC, stack, address space and b) single thread of control Is it desirable to have multiple threads of control that share a single address space? Example: file server and database server
Threads are like "mini" processes (called light-weight processes); each thread has its own PC and stack, and runds strictly sequentially. Different threads are not as independent as different processes. Why?
What threads offer? responsiveness via parallelism: respond while performing other tasks retaining the idea of sequential processes using blocking system calls efficient: fast thread creation and reduced context switching overhead easy software development (coordinating processes) sharing: easy to share data User threads vs kernel threads
User threads: nachos supported by user-level thread libraries (kernel has no knowledge) fast to create and manage (no kernel support) all threads share their processโ time slice Kernel threads: most OS support them handling pre-emption is easier at kernel level thread creation/scheduling is more expensive number of threads typically limited Multithreading models: M-to-1, 1-to-1, M-to-M
Thread pools thread creation is expensive, even with user threads keep pool of idle threads available starting a new thread is faster; also limits number of threads example: web server Thread libraries Pthreads (IEEE POSIX standard), WIN32 (for Windows), Java threads
Message communication between processes/threads Communication using shared data vs without shared data.
Components of message communication: Message = a piece of information that is passed from one process to another. Mailbox = a place where messages are stored until they are received. Operations: Send: copy a message into mailbox. What if the mailbox is full? Receive: copy message out of mailbox, delete from mailbox. What if empty? Is there really no sharing? Two general styles of message communication: 1-way: messages flow in a single direction (Unix pipes, or producer/consumer style). 2-way: messages flow back-and-forth (remote procedure call, or client/server style). Producer & consumer example (1-way):
Note that this looks a lot like a procedure call&return. Analogs between procedure calls and
message operations:
Parameters: request message ( read myfile ) Result: return message ( contents of myfile ) Name of procedure: mbox Return address: mbox. The return address is hardwired in this example. Any problem?
Why use messages? Many applications fit into the model of processing a sequential flow of information. The communicating parties can be totally separate, except for the mailbox: Less error-prone, because no invisible side effects. They might not trust each other (OS vs. user). They might have been written at different times by different programmers. They might be running on different processors on a network, so ...
Message systems vary along several dimensions:
Relationship between mailboxes and processes: One mailbox per process, use process name in send, no name in receive. No strict mailbox-process association, use mailbox name.
Extent of buffering: Buffering (efficient transfers when sender and receiver run at different rates). None -- rendezvous protocols (simple; OK for call-return type communication).
Waiting (blocking vs. non-blocking ops): Blocking receive: return message; if empty, wait until message arrives.
Non-blocking receive: return message; if empty, return special โโemptyโโ value. Blocking send: wait until mailbox has space. Non-blocking send: return โโfullโโ if no space in mailbox.
Additional forms of waiting: Many processes wait on the same mailbox at the same time. One process wait on several mailboxes at once (e.g. select in UNIX).
Constraints on messages: None: just a stream of bytes (Unix pipes). Enforce message boundaries (send and receive in same chunks). More constraints (e.g. process id of sender): security issues
How do the following mechanisms relate to the above classifications? Semaphores Condition variables
Are messages and shared-data approaches are equally powerful? Do they result in very different-looking styles of programming? Which one is easier to work with for most people?
