Semaphore Architecture for Multi-threaded Multi-masking Operating Systems
Original Publication Date: 1991-Sep-01
Included in the Prior Art Database: 2005-Apr-03
Cook, RL: AUTHOR [+4]
Described is a software facility for semaphore architecture to be used in multi-threaded multi-masking operating systems. Discussed are seven semaphore interfaces that reflect application programmer implementation pertaining to 32-bit Operating System/2* (OS/2*) products.
Semaphore Architecture for Multi-threaded Multi-masking
a software facility for semaphore
architecture to be used in multi-threaded multi-masking operating
systems. Discussed are seven semaphore interfaces that reflect
application programmer implementation pertaining to 32-bit Operating
System/2* (OS/2*) products.
semaphore interface areas that reflect application
programmer implementation involve the 32-bit semaphore application
programming interface (API) requirements designed to provide the
1) A system-wide limit of 64K shared semaphores and a pre-process
limit of 64K private semaphores. A running process will therefore
have access to a theoretical maximum of 128K semaphores which
are subject to constraints imposed by other system resources.
2) A single wakeup guarantee. Spurious wakeups are a
side-effect of the 16-bit implementation and will be eliminated.
3) Three different kinds of semaphores: mutual exclusion
(mutex); event; and multiple wait (muxwait). Each semaphore is
designed to be used in a specific way and addresses overloading.
4) Event semaphores that are edge-triggered to eliminate the
possibility of any missed SemClear problems.
5) To insure that all semaphores are cleaned by the system at
task-termination time. If the owner of a semaphore dies before the
semaphore is released, the application/dynlink should be in
formed of this fact so that it can take the necessary steps to
correct, or clean up, the resources protected by the semaphore.
6) New query operations that allow any thread to determine the state
of a semaphore that is visible to it.
7) The 32-bit semaphore services, except create and destroy, and
to be at least as fast as the 16-bit fast-safe random-access memory
(RAM) semaphore services when called from Ring 3.
outlines how each of the seven requirements are
requirement is attained by creating a system-wide map
capable of representing 64K shared semaphores. The semaphores
location in the system-wide map is used to determine the semaphore's
handle that is returned to the client application. In addition,
there is an analogous structure associated with each process capable
of mapping 64K private semaphores, again with a mapping between
location of the semaphore and its handle.
requirement is attained by using a new block/wakeup
mechanism. The ProcBlock/ProcRun routines are rewritten to guarantee
a single wakeup. The new routines are called TKSleep and TKWakeup.
The block identifications (IDs) are required to be unique and
therefore eliminate the possible duplication of block IDs t...