16-bit Semaphores

There are three types of 16-bit semaphores, namely system, RAM, and fast-safe RAM semaphores. There are compromises involved in using each.

System Semaphores

These are the most robust of the three, and have the most overhead.

One thread must create the semaphore, with DosCreateSem, which has a name in a format similar to a file name, but in root directory 'SEM'. Other threads must open it with DosOpenSem to get its handle.

Use is to issue DosSemRequest, use the resource, and then to issue DosSemClear so that other threads can access the resource. All threads should issue DosCloseSem before ending.

If a thread ends while owning a system semaphore, the first requestor is given a return code that indicates the situation, so that it is warned of a possibly incomplete update, and may take whatever action is necessary to recover, or terminate.

To find out which thread owns a system semaphore, display a word at the address provided in the blocking data. The address will be a logical address using a GDT selector, generally 400:xxxx. The 12 low order bits are the slot number of the thread which owns the semaphore. If unowned, the value is zero.

RAM Semaphores (RamSems)

At the opposite end of the scale is the extremely fast RamSem. Most of the speed comes from the following facts:

API's use the address of the RamSem as the handle.

OS/2 assumes a RamSem is local to a process.

OS/2 does absolutely no accounting for a RamSem.

OS/2 can not provide any recovery for a RamSem.

A RamSem is owned by a user thread if the first byte is hex 'FF', otherwise it is not owned by a user thread. Unless you have a trace, there is no way to determine which thread owns a RamSem.

Fast-Safe RAM Semaphores (FSRamSems)

The FSRamSem is a compromise between the two earlier types.

The FSRamSem is nothing more than a structure which includes a RamSem. The fields of the structure record the process ID (PID) and thread ID (TID) of the thread which owns the semaphore, or zero if unowned. They also include a use count, which is incremented if the owning thread again requests the semaphore. This allows recursive functions to serialize without being blocked, waiting for a resource the thread already owns.

The DosFSRamSemRequest API is used to request the semaphore. It returns when the resource is owned by the thread.

The DosFSRamSemClear API is used to release the semaphore. If the use count is not zero after being decremented, the semaphore is NOT released. There must be as many 'Clear' as 'Request' API calls to actually release the semaphore, and allow other threads to compete for it.

[Back: Semaphores]
[Next: 32-bit Semaphores]