IBM 000-8697 User Manual

Page of 702
System Architecture
2-43
Managing Shared-Memory Resources
Semaphores
When an OnLine user process attempts to acquire a latch and finds that the
latch is unavailable, the user process can block until the latch is available. The
mechanism that signals the process to wake when the latch becomes
available is a
UNIX
semaphore.
The semaphore mechanism works likes this. Every OnLine user process is
associated with a semaphore. If a user process finds a latch unavailable, the
semaphore associated with the process is placed on a list of waiting
semaphores. When the user process holding the latch is ready to release it, the
holding user process looks to see if any user processes are waiting for the
latch. If so, the holding process releases the latch and wakes the first appro-
priate user process in the semaphore list.
If the latch to be released is a buffer latch, the holding user process wakes the
first waiting process that has a compatible lock access type. (Refer to
 for further information about buffer acquisition.)
All semaphores are created when shared memory is created. In most
UNIX
operating systems, the number of semaphores permitted is equal to the
maximum number of concurrent user processes, specified as
USERS
 in the
OnLine configuration file.
UNIX
kernel parameters can affect the number of semaphores created by your
UNIX
 operating system. (Refer to
played by
UNIX
 kernel parameters.)
Forced Abort
If you explicitly kill a user process that is holding a latch, OnLine immedi-
ately initiates an abort to preserve data consistency. If an OnLine user process
is holding a latch, the implication is that the user process is intent on
modifying shared memory. When a user process terminates, the tbinit
daemon initiates proper cleanup, releasing all locks and other resources held
by the user process.
Although tbundo can perform routine cleanup for processes that die prema-
turely, data consistency prevents tbinit from releasing shared-memory
latches as part of cleanup. It is impossible for tbinit to determine whether the
user process concluded its modifications before it was terminated or if the
database is in a consistent state.