On single-processor systems, semaphores are used to synchronize the activities of server and self-service client processes that are connected to a database. By default, each database has an array of semaphores, one for each user or server. Each process uses its semaphore when it must wait for a shared resource. Semaphores are not used for single-user sessions or for client sessions connecting to a remote database on a server system.
The following figure shows how semaphores control access to shared resources.
Figure 40. How a semaphore coordinates concurrent access
When process 5 needs access to a record, index, or other shared resource already locked by process 8, process 5 decrements its semaphore. When the process holding the lock (process 8) releases the resource, it notifies the waiting process (process 5) by incrementing the semaphore.
Semaphores are grouped into semaphore sets. Each semaphore set has a unique identifying number called a semid. Within a semaphore set, individual semaphores are identified by an integer ranging from 0 to one less than the size of the semaphore set.
The OpenEdge broker preallocates semaphores when you start the database with PROSERVE. Each process requires one semaphore. The broker uses two additional semaphores internally. The database engine uses the following formula to determine the number of semaphores (#SEM) to allocate:
If you set this value too low, the database engine might generate error 1093 or 1130.
SEMMNS
Total number of semaphores allowed for the system
SEMMSL * number of active databases.
If you set this value too low, the database engine might generate error 1093, 1131, or 1195.
SEMMNU
Maximum number of semaphore undo structures allowed for the system
Same value as SEMMNS.
If you set this value too low, the database engine might generate error 1081.
When you install the OpenEdge RDBMS, you might have to increase the values of these parameters. If you are running other software that uses semaphores, take into account the combined requirements. See your system documentation for information on how to change these parameters.
The amount of kernel memory required for semaphores is relatively small, so setting the limits higher than your current needs probably will not affect performance.
The PROMON R&D Shared Resources option displays the number of semaphores used. When you start the broker process, a message specifies the number of semaphores still available. If the number of database users grows large, the database engine might exceed the maximum number of semaphores allowed, specified by the SEMMNS parameter. If this happens, you must reconfigure the system's kernel to increase the semaphore limit. You can reduce semaphore use only by lowering the values of the Number of Users (-n) and/or Maximum Servers (-Mn) startup parameters.
