OS SERVICES - Semaphores

Semaphores

The CommonPoint application system provides two kinds of semaphores: readers/writer locks and counting semaphores, though the readers/writer lock style of semaphore is preferred.

A readers/writer lock semaphore contains no explicit reference associating it with the shared data it protects. You maintain the association simply by programming cooperating threads to acquire the semaphore before accessing the data. This style of programming allows multiple threads (readers) to read the data associated with the semaphore simultaneously, but allows only one thread at a time (a writer) to modify the data.

When a thread acquires a readers/writer lock in shared mode, other threads can also hold the lock in shared mode at the same time. When a thread acquires the lock in restricted mode, no other thread can hold or acquire the lock until it's released. By convention you only use shared mode for reading the data associated with the semaphore; you use restricted mode for writing.

When using a semaphore to represent an operation rather than data, releasing restricted access to the semaphore could signal the end of the operation. Other threads that depend on the operation being complete could simply acquire the semaphore in restricted mode before proceeding. You can use a message stream to accomplish this coordination if you need to communicate detailed information between threads, but this method is slower than using a semaphore. See Chapter 2, "Streams," in Foundation Services to learn about message streams.

Local and recoverable semaphores

The CommonPoint application system provides two kinds of readers/writer lock semaphores: local semaphores, which can only be used within tasks, and recoverable semaphores, which can be shared among tasks. A recoverable semaphore has the ability to recover when the thread holding the semaphore unexpectedly terminates without releasing the semaphore; in this case, the recoverable semaphore restores itself to an unlocked state and unblocks any threads waiting to acquire it. This capability is essential for preventing deadlocks involving semaphores that are shared among tasks.

These rules govern the acquisition and release of readers/writer lock semaphores:

A thread that acquires a semaphore in restricted mode becomes the owner of the semaphore. Once the semaphore is acquired in restricted mode, no other thread can acquire the semaphore in any mode, and only the owner is allowed to release the semaphore.
When a thread attempts to acquire a semaphore in restricted mode while any other threads hold the semaphore in either mode, the thread blocks until all other threads release the semaphore.
When a thread releases restricted-mode ownership of a semaphore, all threads waiting to acquire the semaphore in shared mode are unblocked (and allowed to acquire the semaphore) before threads waiting to acquire the semaphore in restricted mode.
Threads waiting to acquire a semaphore in restricted mode are allowed to acquire the semaphore on a first-come-first-served basis.
When a semaphore is destroyed, all threads waiting to acquire it receive a TKernelException with an error code of kSemaphoreDeleted.

[Contents] [Previous] [Next]

Click the icon to mail questions or corrections about this material to Taligent personnel.

Copyright©1995 Taligent,Inc. All rights reserved.

Generated with WebMaker