Berkeley DB Reference Guide:
Programmer Notes

 PrevRefNext

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:

(버클리 디비는 내부적으로 쓰래드를 사용하지 않는다.포팅 문제 때문이다.라이브러리 함수에서 리턴된 디비 환경과 디비오브젝트는 쓰레드에 자유롭고 그외는 자유롭지 않다. 쓰레드로 라이브러리를 접근할때 다음의 룰을 따르기 바란다.)

　

  1. 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.

    ( DB_ENV->open , DB->open 에 DB_THREAD 플래그를 설정해야 한다. )

    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.

    (오직 하나의 쓰레드만이 DB_ENV->close or DB->close를 호출.)

    No other Berkeley DB handles are free-threaded.

    (다른 핸들은 쓰레드에 자유롭지 못하다.)

    　

  2. 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.

    (커서를 사용하지 않고 키/데이타 를 읽을때 DBT에 저장된 포인터는 DB핸들을 사용하는 다음 함수콜까지 유효하다.이 함수콜은 쓰레드들에 의해 호출될때도 마찬가지다.)

    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.

    (이같은 이유로  DB->open에 DB_THREAD를 설정했다면 넌커서 키/데이타 읽기에서는 DB_DBT_MALLOC, DB_DBT_REALLOC, or DB_DBT_USERMEM가 DBT에 설정되어야 한다.)

    　

  3. 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.

    (트랜젝션과 커서는 쓰레드들 사이에서 확장되어 적용될 수 있다.그러나 오직 시리얼적으로 동작해야 한다.즉 애플리케이션은 DB_TXN and DBC handles을 순차적으로 접근해야 한다.내포된 프랜젝션의 경우 모든 자식 트랜젝션은 하나의 같은 부모 트랜젝션의 일부분이다.또한 이들은 같은 제약조건을 준수하게 된다.즉 자식트랜젝션은 각 자식이 시리얼적으로 오직 실행될때만이 여러 다른 쓰레드에서 실행가능하다.)

    　

  4. 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.

    (사용자 레벨 동기화 뮤텍스는 컴파일러/아키텍쳐 조합에 의해 구현되어야 한다.만약 빠른 뮤텍스가 사용가능하지 않다면  DB_THREAD플래그의 설정은 실패하게 된다.)

     

    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.

    (애플리케이션베이스의 yield함수를 설정할수 있다. db_env_set_func_yield참조)

    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.
    (대기전에 뮤텍스를 얻기위한 시도횟수를 설정할수 있다. DB_ENV->set_tas_spins 참조)

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.

(단일 물리적 파일에 멀티 디비를 생성할때 멀티쓰레드 프로그램은 추가적으로 준수해야 할게 있다. Opening multiple databases in a single file.참조)


PrevRefNext

Copyright (c) 1996-2003 Sleepycat Software, Inc. - All rights reserved.