Introduction to the locking subsystem

The Lock subsystem is created, initialized, and opened by calls to DB_ENV->open() with the or DB_INIT_CDB flags specified.

The method is used to acquire and release locks. The DB_ENV->lock_vec() method performs any number of lock operations atomically. It also provides the capability to release all locks held by a particular locker and release all the locks on a particular object. (Performing multiple lock operations atomically is useful in performing Btree traversals — you want to acquire a lock on a child page and once acquired, immediately release the lock on its parent. This is traditionally referred to as lock-coupling). Two additional methods, and DB_ENV->lock_put(), are provided. These methods are simpler front-ends to the functionality, where DB_ENV->lock_get() acquires a lock, and releases a lock that was acquired using DB_ENV->lock_get() or . All locks explicitly requested by an application should be released via calls to DB_ENV->lock_put() or . Using DB_ENV->lock_vec() instead of separate calls to and DB_ENV->lock_get() also reduces the synchronization overhead between multiple threads or processes. The three methods are fully compatible, and may be used interchangeably.

The function returns a unique ID that may safely be used as the locker parameter to the DB_ENV->lock_vec() method. The access methods use to generate unique lockers for the cursors associated with a database.

The DB_ENV->lock_detect() function provides the programmatic interface to the Berkeley DB deadlock detector. Whenever two threads of control issue lock requests concurrently, the possibility for deadlock arises. A deadlock occurs when two or more threads of control are blocked, waiting for actions that another one of the blocked threads must take. For example, assume that threads A and B have each obtained read locks on object X. Now suppose that both threads want to obtain write locks on object X. Neither thread can be granted its write lock (because of the other thread’s read lock). Both threads block and will never unblock because the event for which they are waiting can never happen.

The function returns information about the status of the lock subsystem. It is the programmatic interface used by the db_stat utility.

The locking subsystem is closed by the call to .

For more information on the locking subsystem methods, see the Locking Subsystem and Related Methods section in the Berkeley DB C API Reference Guide.