Browse Prior Art Database

Semaphore Architecture for Multi-threaded Multi-masking Operating Systems

IP.com Disclosure Number: IPCOM000121703D
Original Publication Date: 1991-Sep-01
Included in the Prior Art Database: 2005-Apr-03

Publishing Venue

IBM

Related People

Cook, RL: AUTHOR [+4]

Abstract

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.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 11% of the total text.

Semaphore Architecture for Multi-threaded Multi-masking Operating
Systems

      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.

      The seven semaphore interface areas that reflect application
programmer implementation involve the 32-bit semaphore application
programming interface (API) requirements designed to provide the
following:
     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.

      The following outlines how each of the seven requirements are
attained:

      The first 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.

      The second 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...