Viewing file:  mt.html (5.69 KB) -rw-r--r--
Select action/file-type:
 (+) | (+) |  (+) | Code (+) | Session (+) |  (+) | SDB (+) |  (+) |  (+) |  (+) |  (+) |  (+) |
Berkeley DB Reference Guide: Multithreaded applications
- Berkeley DB Reference Guide:
- Programmer Notes
|
  
|
Multithreaded applications
Berkeley DB fully supports multithreaded applications. The Berkeley DB library is
not itself multithreaded, and was deliberately architected to not use
threads internally because of the portability problems that would
introduce. Database environment and database object handles returned
from Berkeley DB library functions are free-threaded. No other object handles
returned from the Berkeley DB library are free-threaded. The following rules
should be observed when using threads to access the Berkeley DB library:
- The DB_THREAD flag must be specified to the DB_ENV->open
and DB->open methods if the Berkeley DB handles returned by those interfaces
will be used in the context of more than one thread. Setting the
DB_THREAD flag inconsistently may result in database corruption.
Threading is assumed in the Java API, so no special flags are required;
and Berkeley DB functions will always behave as if the DB_THREAD flag
was specified.
Only a single thread may call the DB_ENV->close or DB->close methods
for a returned environment or database handle.
No other Berkeley DB handles are free-threaded.
- When using the non-cursor Berkeley DB calls to retrieve key/data items (for
example, DB->get), the memory to which the pointer stored into
the Dbt refers is valid only until the next call using the DB
handle returned by DB->open. This includes any use of
the returned DB handle, including by another thread within the
process.
For this reason, if the DB_THREAD handle was specified to the
DB->open method, either DB_DBT_MALLOC, DB_DBT_REALLOC,
or DB_DBT_USERMEM must be specified in the DBT when
performing any non-cursor key or data retrieval.
- Cursors may not span transactions. Each cursor must be
allocated and deallocated within the same transaction.
Transactions and cursors may span threads, but only serially, that is,
the application must serialize access to the DB_TXN and
DBC handles. In the case of nested transactions, since all
child transactions are part of the same parent transaction, they must observe
the same constraints. That is, children may execute in different threads
only if each child executes serially.
- User-level synchronization mutexes must have been implemented for the
compiler/architecture combination. Attempting to specify the DB_THREAD
flag will fail if fast mutexes are not available.
If blocking mutexes are available (for example POSIX pthreads), they
will be used. Otherwise, the Berkeley DB library will make a system call to
pause for some amount of time when it is necessary to wait on a lock.
This may not be optimal, especially in a thread-only environment, in
which it is usually more efficient to explicitly yield the processor to
another thread.
It is possible to specify a yield function on an per-application basis.
See db_env_set_func_yield for more information.
It is possible to specify the number of attempts that will be made to
acquire the mutex before waiting. See DB_ENV->set_tas_spins for
more information.
When creating multiple databases in a single physical file, multithreaded
programs may have additional requirements. For more information, see
Opening multiple databases in a single
file.
Copyright (c) 1996-2004 Sleepycat Software, Inc. - All rights reserved.
|