View
238
Download
2
Embed Size (px)
Citation preview
Chapter 7: Process Synchronization10/14/03
Background The Critical-Section Problem Synchronization Hardware Semaphores Classical Problems of Synchronization Critical Regions Monitors Synchronization in Solaris 2 & Windows 2000
NOTE: Instructor annotations in BLUE
Background
Concurrent access to shared data may result in data inconsistency.
Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes.
Shared-memory solution to bounded-butter problem (Chapter 4) allows at most n – 1 items in buffer at the same time. A solution, where all N buffers are used is not simple. Suppose that we modify the producer-consumer code by
adding a variable counter, initialized to 0 and incremented each time a new item is added to the buffer
Bounded-Buffer
Shared data
#define BUFFER_SIZE 10
typedef struct {
. . .
} item;
item buffer[BUFFER_SIZE];
int in = 0;
int out = 0;
int counter = 0;
Bounded-Buffer
Producer process
item nextProduced;
while (1) {
while (counter == BUFFER_SIZE)
; /* do nothing */
buffer[in] = nextProduced;
in = (in + 1) % BUFFER_SIZE;
counter++;
}
Bounded-Buffer
Consumer process
item nextConsumed;
while (1) {while (counter == 0)
; /* do nothing */nextConsumed = buffer[out];out = (out + 1) % BUFFER_SIZE;counter--;
}
Bounded Buffer
The statements
counter++;counter--;
must be performed atomically.
Atomic operation means an operation that completes in its entirety without interruption.
Bounded Buffer Analysis
Although “P” and “C” routines are logically correct in themselves, they may not work correctly running concurrently.
The counter variable is shared between the two processes
When ++counter and --count are done concurrently, the results are unpredictable because the operations are not atomic
Assume ++counter, --counter compiles as follows: ++counter --counter
register1 = counter register2 = counter register1 = register1 + 1 register2 = register2 - 1 counter = register1 counter = register2
Bounded Buffer Analysis
If both the producer and consumer attempt to update the buffer concurrently, the assembly language statements may get interleaved.
Interleaving depends upon how the producer and consumer processes are scheduled.
P and C get unpredictable access to CPU due to time slicing
Bounded Buffer Analysis
Assume counter is initially 5. One interleaving of statements is:
producer: register1 = counter (register1 = 5)producer: register1 = register1 + 1 (register1 = 6)consumer: register2 = counter (register2 = 5)consumer: register2 = register2 – 1 (register2 = 4)producer: counter = register1 (counter = 6)consumer: counter = register2 (counter = 4)
The value of count may be either 4 or 6, where the correct result should be 5.We have a “race condition” here.
Race Condition
Race condition: The situation where several processes access – and manipulate shared data concurrently. The final value of the shared data depends upon which process finishes last.
To prevent race conditions, concurrent processes must be synchronized.
Is there any logical difference in a race condition if the two “racing” processes are on two distinct CPU’s in an SMP environment vs. both running concurrently on a single uniprocessor? … is one worse than the other?
The Critical-Section Problem
n processes all competing to use some shared data Each process has a code segment, called critical section,
in which the shared data is accessed. Problem – ensure that when one process is executing in
its critical section, no other process is allowed to execute in its critical section.
Solution to Critical-Section Problem1. Mutual Exclusion. If process Pi is executing in its critical section, then no other
processes can be executing in their critical sections – unless it is by deliberate design by the programmer – see readers/writer problem later.
2. *Progress. If there exist some processes that wish to enter their critical section, then processes outside of their critical sections cannot participate in the decision of which one will enter its CS next, and this selection cannot be postponed indefinitely.In other words: No process running outside its CS may block other processes from entering their CS’s – ie., a process must be in a CS to have this privilege.
3. Bounded Waiting. A bound must exist on the number of times that other processes are allowed to enter their critical sections after a process has made a request to enter its critical section and before that request is granted - no starvation.Assume that each process executes at a nonzero speed No assumption concerning relative speed of the n processes.
* Item 2 is A modification of the rendition given in Silberschatz which appears to be “muddled” – see “Modern Operating Systems”, 1992, by Tanenbaum, p. 35.See next slide ffrom other author’s rendition of these conditions for clarification:
Solution to Critical-Section Problem
From: “Operating systems”, by William Stallings, 4th ed., page 207 Mutual exclusion must be enforced: Only one process at a time is allowed
into the critical section (CS) A process that halts in its noncritical section must do so without interfering
with other processes It must not be possible for a process requiring access to a CS to be delayed
indefinitely: no deadlock or starvation. When no process is in a critical section, any process that requests entry to its
CS must be permitted to enter without delay. No assumptions are made about relative process speeds or number of
processors. A process remains inside its CS for a finite time only.
Also From “Modern Operating Systems”, 1992, by Tanenbaum, p. 35.- No two processes may be simultaneously inside their critical sections.- No assumptions may be made about speeds or the numbers of CPUs- No process running outside its CS may block other processes from entering their CS’s - No process should have to wait forever to enter its CS
Initial Attempts to Solve Problem
Only 2 processes, P0 and P1
General structure of process Pi (other process Pj)
do {
entry section
critical section
exit section
reminder section
} while (1); Processes may share some common variables to
synchronize their actions.
Algorithm 1 Assume two processes: P0 and P1
Shared variables: int turn;
initially turn = 0 /* let P0 have turn first */ if (turn == i) Pi can enter its critical section, i = 0, 1
For process Pi : // where the “other” process is Pj
do { while (turn != i) ; // wait while it is your turn critical section turn = j; // allow the “other” to enter after exiting CS reminder section} while (1);
Satisfies mutual exclusion, but not progress if Pj decides not to re-enter or crashes outside CS, then Pi cannot ever get in A process cannot make consecutive entries to CS even if “other” is not in CS - other
prevents a proc from entering while not in CS - a “no-no”
Algorithm 2 Shared variables
boolean flag[2]; // “interest” bitsinitially flag [0] = flag [1] = false.
flag [i] = true Pi declares interest in entering its critical section Process Pi // where the “other” process is Pj
do { flag[i] = true; // declare your own interest while (flag[ j]) ; //wait if the other guy is interested critical section flag [i] = false; // declare that you lost interest remainder section // allows other guy to enter} while (1);
Satisfies mutual exclusion, but not progress requirement. If flag[ I] == flag[ j] == true, then deadlock - no progress but barring this event, a non-CS guy cannot block you from entering Can make consecutive re-entries to CS if other not interested Uses “mutual courtesy”
Algorithm 3 Peterson’s solution Combined shared variables & approaches of algorithms 1 and 2. Process Pi // where the “other” process is Pj
do {flag [i] = true; // declare your interest to enter
turn = j; // assume it is the other’s turn-give PJ a chance while (flag [ j ] and turn == j) ;
critical sectionflag [i] = false;
remainder section} while (1);
Meets all three requirements; solves the critical-section problem for two processes (the best of all worlds - almost!). Turn variable breaks any deadlock possibility of previous example,
AND prevents “hogging” – Pi setting turn to j gives PJ a chance after each pass of Pi’s CS
Flag[ ] variable prevents getting locked out if other guy never re-enters or crashes outside and allows CS consecutive access other not intersted in entering.
Down side is that waits are spin loops. Question: what if the setting flag[i], or turn is not atomic?
Bakery Algorithm… or the Supermarket deli algorithm
Before entering its critical section, process receives a number. Holder of the smallest number enters the critical section.
If processes Pi and Pj receive the same number, if i < j, then Pi is served first; else Pj is served first.
The numbering scheme always generates numbers in increasing order of enumeration; i.e., 1,2,3,3,3,3,4,5...
Critical section for n processes
Bakery Algorithm
Notation < lexicographical order (ticket #, process id #) (a,b) < c,d) if a < c or if a = c and b < d max (a0,…, an-1) is a number, k, such that k ai
for i = 0, … , n – 1 Shared data
boolean choosing[n];
int number[n];
Data structures are initialized to false and 0 respectively
Bakery Algorithm For Process Pi do { /* Has four states: choosing, scanning, CS, remainder section */
choosing[i] = true; //process does not “compete” while choosing a #number[i] = max(number[0], number[1], …, number [n – 1]) + 1;choosing[i] = false; /*scan all processes to see if if Pi has lowest number: */for (k = 0; k < n; k++) { /* check process k, book uses dummy variable “j” */
while (choosing[ k ]); /*if Pk is choosing a number wait till done */
while ((number[k] != 0) && (number[k], k < number[ i ], i)) ; /* if (Pk is waiting (or in CS) and Pk is “ahead” of Pi then Pi waits */
/*if Pk is not in CS and is not waiting, OR Pk is waiting with a larger number, then skip over Pk - when Pi gets to end of scan, it will have lowest number and will fall thru to the CS */
/* If Pi is waiting on Pk, then number[k] will go to 0 because Pk will eventually get served – thus causing Pi to break out of the while loop and check out the status of the next process if any */
/* the while loop skips over the case k == i */}
critical sectionnumber[i] = 0; /* no longer a candidate for CS entry */
remainder section} while (1);
Synchronization HardwareTest and Set
targer is the lock: target ==1 means cs locked, else open Test and modify the content of a word atomically.
boolean TestAndSet(boolean target) {
boolean rv = target;
target = true;
return rv; // return the original value of target
} See “alternate definition” in “Principles of Concurrency” notes
if target ==1 (locked), target stays 1 and return 1, “wait” if target ==0 (unlocked), set target to 1(lock door), return 0, and
enter “enter CS”
Mutual Exclusion with Test-and-Set
Shared data: boolean lock = false; // if lock == 0, door open, if lock == 1, door locked
Process Pi
do {
while (TestAndSet(lock)) ;
critical section
lock = false;
remainder section
} See Flow chart (“Alternate Definition” ) in Instructors notes:
“Concurrency and Mutual exclusion”, Hardware Supportfor details on how this works.
Synchronization Hardwareswap
Atomically swap two variables.void Swap(boolean &a, boolean &b) {
boolean temp = a;
a = b;
b = temp;
}
Mutual Exclusion with Swap for process Pi Shared data (initialized to false):
boolean lock = false; /* shared variable - global */// if lock == 0, door open, if lock == 1, door locked
Private databoolean key_i = true;
Process Pi
do {key_i = true; /* not needed if swap used after CS exit */while (key_i == true)
Swap(lock, key_i );critical section /* remember key_i is now false */
lock = false; /* can also use: swap(lock, key_i ); */remainder section
} See Flow chart (“Alternate Definition” ) in Instructors notes: “Concurrency and
Mutual exclusion”, Hardware Supportfor details on how this works. NOTE: The above applications for mutual exclusion using both test and set and swap do not satisfy bounded waiting requirement - see book pp.199-200 for resolution..
Semaphores
Synchronization tool that does not require busy waiting. Semaphore S – integer variable can only be accessed via two indivisible (atomic) operations
wait (S): while S 0 do no-op; S--;
signal (S): S++;
Note: Test before decrement Normally never negative No queue is used (see later) What if more than 1 process is waiting on S and a signal occurs? Employs a spin loop (see later)
Critical Section of n Processes
Shared data: semaphore mutex; //initially mutex = 1
Process Pi:
do { wait(mutex); critical section
signal(mutex); remainder section} while (1);
Semaphore Implementation
Get rid of the spin loop, add a queue, and increase functionality (counting semaphore)
Used in UNIX
Define a semaphore as a recordtypedef struct { int value; struct process *L;} semaphore;
Assume two simple operations: Block(P) suspends (blocks) the process P. wakeup(P) resumes the execution of a blocked process P.
Must be atomic
Implementation- as in UNIX
Semaphore operations called by process P now defined as wait(S):
S.value--; //Note: decrement before testif (S.value < 0) {
add this process to S.L;block(P); //block the process calling wait(S)
}
// “door” is locked if S.value <= 0;
signal(S): S.value++;if (S.value <= 0) { // necessary condition for non-empty queue
remove a process P from S.L;wakeup(P); //move P to ready queue
} /* use some algorithm for choosing a process to remove from queue, ex: FIFO */
Implementation- continued Compare to original “classical” definition: Allows for negative values (“counting” semaphore)
Absolute value of negative value is number of processes waiting in the semaphore
Positive value is the number of processes that can call wait and not block
Wait() blocks on negative Wait() decrements before testing Remember: signal moves a process to the ready queue, and
not necessarily to immediate execution
How is something this complex made atomic? Most common: disable interrupts Use some SW techniques such as Peterson’s solution inside
wait and signal – spin-loops would be very short (wait/signal calls are brief) – see p. 204 … different than the spin-loops in classical definition!
Implementation- continued
The counting semaphore has two fundamental applications:
Mutual exclusion for solving the “CS” problem Controlling access to resources with limited availability,
for example in the bounded buffer problem: block consumer if the buffer empty block the producer if the buffer is full.
Both applications are used for the bounded buffer problem
Semaphore as a General Synchronization Tool
Execute B in Pj only after A executed in Pi
Serialize these events (guarantee determinism): Use semaphore flag initialized to 0 Code:
Pi Pj
A wait(flag)
signal(flag) B
Deadlock and Starvation Just because semaphores can solve the “CS” problem, they still
can be misused and cause deadlock or starvation
Deadlock – two or more processes are waiting indefinitely for an event that can be caused by only one of the waiting processes.
Let S and Q be two semaphores initialized to 1
P0 P1
(1) wait(S); (2) wait(Q); (3) wait(Q); (4) wait(S);
signal(S); signal(Q);signal(Q) signal(S);
Random sequence 1, 2, 3, 4 causes deadlockBut sequence 1, 3, 2, 4 will not deadlock
Starvation – indefinite blocking. A process may never be removed from the semaphore queue in which it is suspended.Can be avoided by using FIFO queue discipline.
Two Types of Semaphores
Counting semaphore – integer value can range over an unrestricted domain.
Binary semaphore – integer value can range only between 0 and 1; can be simpler to implement.
Can implement a counting semaphore S as a binary semaphore.
Binary Semaphore DefinitionStruct b-semaphore {
int value; /* boolean, only 0 or 1 allowed */struct process queue;
}Void wait-b (b-semaphore s) { /* see alternate def. Below */
if (s.value == 1) s.value = 0; // Lock the “door” & let process enter CSelse { place this process in s.queue and block it;} // no indication of size of queue ... compare to general semaphore
} // wait unconditionally leaves b-semaphore value at 0Void signal-b(b-semaphore s) { //s.value==0 is necessary but not sufficient
if (s.queue is empty) s.value = 1; // condition for empty queueelse move a process from s.queue to ready list;
} // if only 1 proc in queue, leave value at 0, “moved” proc will go to CS *********************************************************************Alternate definition of wait-b (simpler):Void wait-b (b-semaphore s) {
if (s.value == 0) {place this process in s.queue and block it;}s.value =0; // value was 1, set to 0
} // compare to test & set
Implementing Counting Semaphore S using Binary Semaphores
Data structures:binary-semaphore S1, S2;int C:
Initialization:S1 = 1S2 = 0C = initial value of semaphore S
Implementing Counting Semaphore S using Binary Semaphores (continued)
wait operationwait(S1);C--;if (C < 0) {signal(S1);wait(S2);}else? signal(S1);
signal operationwait(S1); //should this be a “different” S1?C ++;if (C <= 0) signal(S2);else // else should be removed?
signal(S1);
See a typical example of semaphore operation given in “Chapter 7 notes by Guydosh” posted along with these notes.
Classical Problems of Synchronization
Bounded-Buffer Problem
Readers and Writers Problem
Dining-Philosophers Problem
Bounded-Buffer Problem Uses both aspects of a counting semaphore:
Mutual exclusion: the mutex semaphore Limited resource control: full and empty semaphores
Shared data:semaphore full, empty, mutex;where:- full represents the number of “full” (used) slots in the buffer
- empty represents the number if “empty” (unused) slots in the buffer
- mutex is used for mutual exclusion in the CSInitially:full = 0, empty = n, mutex = 1 /* buffer empty, “door” is open */
Bounded-Buffer Problem Producer Process
do { …
produce an item in nextp …
wait(empty);wait(mutex);
…add nextp to buffer
…signal(mutex);signal(full);
} while (1);
Question: what may happen if the mutex wait/signal calls were done before and after the corresponding calls for empty and full respectively?
Bounded-Buffer Problem Consumer Process
do { wait(full)wait(mutex); …remove an item from buffer to nextc …signal(mutex);signal(empty); …consume the item in nextc …} while (1);
Same Question: what may happen if the mutex wait/signal calls were done before and after the corresponding calls for empty and full respectively?
See the trace of a bounded buffer scenario given in “Chapter 7 notes by Guydosh” posted along with these notes.
Readers-Writers Problem Semaphores used purely for mutual exclusion
No limits on writing or reading the buffer
Uses a single writer, and multiple readers Multiple readers allowed in CS Readers have priority over writers for these slides. As long as there is a reader(s) in the CS, no writer may enter – CS must be
empty for a writer to get in An alternate (more fair approach) is: even if readers are in the CS, no more
readers will be allowed in if a writer “declares an interest” to get into the CS – this is the writer preferred approach. It is discussed in more detail in Guydosh’s notes: “Readers-Writers problems Scenario” on the website.
Shared datasemaphore mutex, wrt;
Initiallymutex = 1, wrt = 1, readcount = 0 /* all “doors” open, no readers in */
Readers-Writers Problem Reader Process
wait(mutex); // 2nd, 3rd, … readers queues on mutex if 1st reader// waiting for a writer to leave (blocked on wrt).// also guards the modification of readcount
readcount++;if (readcount == 1) wait(wrt); //1st reader blocks if any writers in CSsignal(mutex); //1st reader is in- open the “floodgates” for its companions …reading is performed …wait(mutex); // guards the modification of readcountreadcount--;if (readcount == 0) signal(wrt); // last reader out lets any queued writers insignal(mutex):
See Guydosh’s notes: “Readers-Writers problems Scenario” (website) for a detailed trace of this algorithm.
Dining-Philosophers Problem
Shared data
semaphore chopstick[5];
Initially all values are 1
Process i
Chopstick i
Chopstick i+1
Dining-Philosophers Problem Philosopher i:
do {wait(chopstick[i]) // left chopstickwait(chopstick[(i+1) % 5]) // right chopstick
…eat …
signal(chopstick[i]);signal(chopstick[(i+1) % 5]);
…think …
} while (1);
This scheme guarantees mutual exclusion but has deadlock – what if all 5 philosophers get hungry simultaneously and all grab for the left chopstick at the same time? .. See Monitor implementation for deadlock free solution … sect 7.7
Critical Regions - omit
High-level synchronization construct A shared variable v of type T, is declared as:
v: shared T Variable v accessed only inside statement
region v when B do S
where B is a boolean expression.
While statement S is being executed, no other process can access variable v.
Critical Regions - omit
Regions referring to the same shared variable exclude each other in time.
When a process tries to execute the region statement, the Boolean expression B is evaluated. If B is true, statement S is executed. If it is false, the process is delayed until B becomes true and no other process is in the region associated with v.
Critical Regions Example – Bounded Buffer - omit
Shared data:
struct buffer {
int pool[n];
int count, in, out;
}
Critical Regions Bounded Buffer Producer Process - omit
Producer process inserts nextp into the shared buffer
region buffer when( count < n) {pool[in] = nextp;in:= (in+1) % n;count++;
}
Critical Regions Bounded Buffer Consumer Process - omit
Consumer process removes an item from the shared buffer and puts it in nextc
region buffer when (count > 0) {nextc = pool[out];out = (out+1) % n;count--;
}
Critical Regions: Implementation region x when B do S - omit
Associate with the shared variable x, the following variables:
semaphore mutex, first-delay, second-delay; int first-count, second-count;
Mutually exclusive access to the critical section is provided by mutex.
If a process cannot enter the critical section because the Boolean expression B is false, it initially waits on the first-delay semaphore; moved to the second-delay semaphore before it is allowed to reevaluate B.
Critical Regions: Implementation – omit
Keep track of the number of processes waiting on first-delay and second-delay, with first-count and second-count respectively.
The algorithm assumes a FIFO ordering in the queuing of processes for a semaphore.
For an arbitrary queuing discipline, a more complicated implementation is required.
Monitors High-level synchronization construct that allows the safe sharing of an
abstract data type among concurrent processes.Closely related to P- thread synchronization – see later.
monitor monitor-name{ // procedures internal to the monitor
shared variable declarationsprocedure body P1 (…) {
. . .}procedure body P2 (…) {
. . .} procedure body Pn (…) {
. . .} {
initialization code}
}
Monitors Rationale for the properties of a monitor:
Mutual exclusion: A monitor implements mutual exclusion by allowing only one process at a time to execute in one of the internal procedures.
Calling a monitor procedure will automatically cause the caller to block in the entry queue if the monitor is occupied, else it will let it in.
On exiting the monitor, another waiting process will be allowed in.
When inside the monitor, management of a limited resource which may not always be available for use:
A process can unconditionally block on a “condition variable” (CV) by calling a wait on this CV. This also allows another process to enter the Monitor while the process calling the wait is blocked.
When a process using a resource protected by a CV is done with it, it will signal on the associated CV to allow another process waiting in this CV to use the resource.
The signaling process must “get out of the way” and yield to the released process receiving the signal by blocking. This preserves mutual exclusion in the monitor - Hoare’s scheme.
Monitors Summary
To allow a process to wait within the monitor, a condition variable must be declared, as
condition x, y; // condition variables Condition variable can only be used with the operations
wait and signal. The operation
x.wait();means that the process invoking this operation is unconditionally suspended until another process invokes
x.signal(); The x.signal operation resumes exactly one suspended
process. If no process is suspended, then the signal operation has no effect.
Monitor With Condition Variables
Entry queue is forMutual exclusion
Condition variable queues may be used for resource management and are the processes waiting on a condition variable.
Dining Philosophers Examplemonitor dp {
enum {thinking, hungry, eating} state[5];condition self[5];void pickup(int i) // following slidesvoid putdown(int i) // following slidesvoid test(int i) // following slidesvoid init() {
for (int i = 0; i < 5; i++)state[i] = thinking;
}}
Philosopher i code (written by user):loop at random times { think dp.pickup(i) //simply calling monitor proc … // invokes mutual exclusion eat; // automatically ... dp.putdown(i)
}
Dining Philosophersvoid pickup(int i) {
state[i] = hungry;test[i]; // if neighbors are not eating, set own state to eating
// signal will go to waste - not blockedif (state[i] != eating)
self[i].wait(); // test showed a neighbor was eating - wait}
void putdown(int i) {state[i] = thinking;// test left and right neighbors … gives them chance to eattest((i+4) % 5); // signal left neighbor if she is hungrytest((i+1) % 5); // signal right neighbor if she is hungry
}
Dining Philosophers
Does more than passively test: changes state and cause a philospher to start eating.
void test(int i) { if ( (state[(I + 4) % 5] != eating) && // left neighbor (state[i] == hungry) && // the process being tested (state[(i + 1) % 5] != eating)) { // right neighbor
state[i] = eating;self[i].signal(); // i starts eating if blocked
} // self[i] is a condition variable
} // else do nothing
Monitor Implementation Using Semaphores Variables
semaphore mutex; // (initially = 1) for mutual exclusion on entrysemaphore next; // (initially = 0) signaler waits on thisint next-count = 0; // # processes (signalers) suspended on next
// Entering the monitor: Each external procedure F will be replaced by (ie., put in monitor as):wait(mutex); // lemme into the monitor! … // block if occupied body of F; // same as a critical section ...// exiting the monitor:if (next-count > 0) // any signalers suspended on next? signal(next) // let suspended signalers in first
// same as getting out of line to fill something // out at the DMV (maybe)
else signal(mutex); // then let in any new guys // Above is the overall monitor:
Mutual exclusion within a monitor is ensured.
Monitor Implementation
For each condition variable x, we have:semaphore x-sem; // (initially = 0) causes a wait on x to blockint x-count = 0; // number of processes waiting on CV x
The operation x.wait can be implemented as:
x-count++; // Time for a napif (next-count > 0) // any signalers queued up?
signal(next); // release a waiting signaler firstelse
signal(mutex); //else let a new guy inwait(x-sem); // unconditionally block on the CVx-count--; // I’m outa here
Monitor Implementation
The operation x.signal can be implemented as:
if (x-count > 0) { //do nothing if nobody is waiting on the CV next-count++; // I am (a signaler) gonna be suspended on next signal(x-sem); // release a process suspended on the CV wait(next); // get out of the way of the released process (Hoare) next-count--; // released process done & it signaled me in}
Monitor Implementation - optional
Conditional-wait construct: x.wait(c); c – integer expression evaluated when the wait operation is
executed. value of c (a priority number) stored with the name of the
process that is suspended. when x.signal is executed, process with smallest
associated priority number is resumed next. Check two conditions to establish correctness of system:
User processes must always make their calls on the monitor in a correct sequence.
Must ensure that an uncooperative process does not ignore the mutual-exclusion gateway provided by the monitor, and try to access the shared resource directly, without using the access protocols.
Solaris 2 Synchronization
Implements a variety of locks to support multitasking, multithreading (including real-time threads), and multiprocessing.
Uses adaptive mutexes for efficiency when protecting data from short code segments.
Uses condition variables and readers-writers locks when longer sections of code need access to data.
Uses turnstiles to order the list of threads waiting to acquire either an adaptive mutex or reader-writer lock.
Windows 2000 Synchronization
Uses interrupt masks to protect access to global resources on uniprocessor systems.
Uses spinlocks on multiprocessor systems.
Also provides dispatcher objects which may act as wither mutexes and semaphores.
Dispatcher objects may also provide events. An event acts much like a condition variable.