Kbase P57114: Does Progress use semaphores on multi-processor machines?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
5/31/2011 |
|
Status: Verified
GOAL:
Does Progress use semaphores on multi-processor machines?
GOAL:
When using -spin, does Progress use semaphores?
GOAL:
When using -spin, do UNIX kernel parameters for semaphores need to be set?
GOAL:
How does Progress use semaphores?
FACT(s) (Environment):
UNIX
Progress/OpenEdge Product Family
FIX:
On single-processor systems, Progress uses semaphores 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, which includes one semaphore 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. As of 10.1A the default number of semaphore sets (-semsets) is three.
Semaphores are used as a mechanism to enable a process to wait for various kinds of events to occur within the database manager when it is running in multi-user mode. When a process is waiting on a semaphore, it is not using any CPU time, except once a minute when a timer interrupts the wait to check for error conditions or record lock wait timeouts.
On multi-processor shared-memory systems, the database engine can use a spin lock algorithm to control access to shared-memory structures. However, though semaphores will be used less when -spin is set, they will still be used.
In a multi-user environment semaphores are always used for certain kinds of waits (such as a wait for a record lock), regardless of the setting of -spin. -spin covers more short-term waits, which are basically latches used by the database storage engine to protect the database during critical activity such as shared memory lookup and updates. Semaphores are not used in single-user mode or on the client side when a database is being accessed in client-server over a network.
The semaphore-based waiting mechanism is used in the following situations:
1. The broker uses a semaphore to indicate the database is not ready for use during the time it is initializing during startup. This semaphore is checked before logging in to the database.
2. When a process connects to a database, it allocates an entry in the user table before it can use any of the other locking mechanisms that exist in the database or use shared data structures. A login semaphore is used for this purpose to prevent two processes from taking the same slot. This same semaphore is used when freeing a slot during disconnect.
3. When a process encounters a record lock conflict, it uses a semaphore to wait until the lock holder wakes it up, e.g. when you want an exclusive lock on a row and someone else already has a share lock. You have to wait until the share lock is released.
4. When a process encounters a condition such that it must wait for another transaction to end before it can proceed, a semaphore is used to wait for the other transaction to end. An example of when this occurs is when a unique index entry has been deleted but the deleting transaction has not committed and you want to insert a new index entry with the same key value.
You have to wait for the transaction to commit before you know if the index entry is really deleted.
5. When a process wants an exclusive schema lock and other processes already have share locks, a semaphore is used for the waiting.
6. There are a variety of internal database operations on shared memory data structures which can involve holding a lock for several milliseconds, possibly doing disk i/o while holding the lock. Semaphores are used for such waits.
7. When -spin is not being used, semaphores are used for controlling access to all shared memory-resident data structures. If the structure is busy, you wait on a semaphore until it is released.
3, 4 and 5 above may involve waiting for relatively long periods of time, perhaps minutes or hours.
In short, semaphores are still used when -spin is set, and the Progress-relevant kernel parameters on UNIX (SEMMSL, SEMMNS, SEMMNI, SEMMNU) should still be set accordingly.