eXtremeDB locking

Locking optimization
eXtremeDB uses two kinds of synchronization primitives - latches and locks. The 
first kind (latch) is a lightweight lock implemented with atomic instructions.  It is 
used, for example, in btree indexes to lock branches.  The second kind (lock) is a 
full size synchronization primitive implemented with kernel-locks (and/or
lightweight atomics for performance, if possible).  One lock is used for the 
eXtremeDB registry and database header, but all other locks applied during 
transaction processing depend on the choice of Transaction Manager:
  MVCC - multiple latches in indexes, multiple latches/locks in transaction 
processing.
  MURSIW – no latches in indexes, multiple latches/locks (but fewer than 
MVCC) in transaction processing.
  EXCLusive - no latches in indexes, one single lock on the transaction queue.
For single-threaded and single-process applications, it is possible to eliminate 
latches and locks completely by employing the EXCLusive Transaction Manager 
and/or “hollow” synchronization implementation. (A sample “hollow” 
synchronization implementation that makes no kernel calls nor atomic operations 
or spinlocks is provided as a template for custom user-defined synchronization in 
the file mcosempty.c located in the target/sync subdirectory.)
The developer has complete choice regarding the transaction manager and lock 
implementations by selecting the transaction manager and synchronization 
implementation libraries.  Most likely the choice will be between MURSIW and 
MVCC based on the characteristics of the application.  For applications having
mostly read-only transactions with occasional updates, MURSIW may be the best 
choice.  If there are a relatively high number of concurrent processes/threads 
attempting to modify the database at the same time, then MVCC will probably be 
the better choice.  If the application is single-threaded, concurrency is not an issue 
and clearly it will perform best with the EXCLusive transaction manager or by 
simply including the mcosempty.c file in the project and no synchronization 
library (see the Release Notes for a more details on synchronization libraries).