Semaphores

OS/2 Version 2.0 provides significantly enhanced semaphore facilities for synchronization between threads and processes. In order to maintain compatibility with 16-bit applications, the task management component handles both the older semaphores implemented in previous versions of OS/2, and the new types introduced in Version 2.0.

OS/2 Version 2.0 provides two classes of semaphores: private and shared semaphores. A process may have up to 64KB of private semaphores, available only to threads within that process, and may also access up to 64KB of shared semaphores, available to all processes in the system.

There are three different types of semaphores in OS/2 Version 2.0:

  • Mutex semaphores provide mutually exclusive access to a particular resource.

  • Event semaphores are used to signal system or application events.

  • MuxWait semaphores may be used when waiting for multiple events to occur or multiple mutex semaphores to clear.

    A particular area of enhancement is that of the suspension/reactivation of threads based on semaphores. In previous versions of OS/2, the internal reactivation of threads was based on a "multiple wakeup" approach. When a thread wished to wait for some event, it was placed in an event ID table. Threads waiting for that event were queued in the order in which their wait request occurred. When the event occurred, all threads waiting for this event would contend for the semaphore, and the first queued thread or the thread with the highest priority would be dispatched. However, this algorithm led to considerable system overhead.

    Under previous versions of OS/2, the event ID table was examined using a linear search to find waiting threads. While this method was acceptable for a system with a maximum of 512 threads, it is clearly not suitable for a system with 4096 threads. OS/2 Version 2.0 provides more sophisticated semaphore services, allowing both "single wakeup" and "multiple wakeup" services in a more efficient manner.

    Under Version 2.0, the event ID table is implemented using a hashing algorithm, thereby increasing the speed of access to the table and thereby improving performance when resolving thread contention. This algorithm provides a more efficient method of handling the 4096 threads allowed under Version 2.0.


    [Back: Waiting On and Terminating Threads]
    [Next: Summary]