1.1 --- /dev/null Thu Jan 01 00:00:00 1970 +0000
1.2 +++ b/extensions/sqlite/sqlite-source/mutex_unix.c Sun Mar 30 07:00:22 2008 +0000
1.3 @@ -0,0 +1,223 @@
1.4 +/*
1.5 +** 2007 August 28
1.6 +**
1.7 +** The author disclaims copyright to this source code. In place of
1.8 +** a legal notice, here is a blessing:
1.9 +**
1.10 +** May you do good and not evil.
1.11 +** May you find forgiveness for yourself and forgive others.
1.12 +** May you share freely, never taking more than you give.
1.13 +**
1.14 +*************************************************************************
1.15 +** This file contains the C functions that implement mutexes for pthreads
1.16 +**
1.17 +** $Id$
1.18 +*/
1.19 +#include "sqliteInt.h"
1.20 +
1.21 +/*
1.22 +** The code in this file is only used if we are compiling threadsafe
1.23 +** under unix with pthreads.
1.24 +**
1.25 +** Note that this implementation requires a version of pthreads that
1.26 +** supports recursive mutexes.
1.27 +*/
1.28 +#ifdef SQLITE_MUTEX_PTHREADS
1.29 +
1.30 +#include <pthread.h>
1.31 +
1.32 +/*
1.33 +** Each recursive mutex is an instance of the following structure.
1.34 +*/
1.35 +struct sqlite3_mutex {
1.36 + pthread_mutex_t mutex; /* Mutex controlling the lock */
1.37 + int id; /* Mutex type */
1.38 + int nRef; /* Number of entrances */
1.39 + pthread_t owner; /* Thread that is within this mutex */
1.40 +#ifdef SQLITE_DEBUG
1.41 + int trace; /* True to trace changes */
1.42 +#endif
1.43 +};
1.44 +
1.45 +/*
1.46 +** The sqlite3_mutex_alloc() routine allocates a new
1.47 +** mutex and returns a pointer to it. If it returns NULL
1.48 +** that means that a mutex could not be allocated. SQLite
1.49 +** will unwind its stack and return an error. The argument
1.50 +** to sqlite3_mutex_alloc() is one of these integer constants:
1.51 +**
1.52 +** <ul>
1.53 +** <li> SQLITE_MUTEX_FAST
1.54 +** <li> SQLITE_MUTEX_RECURSIVE
1.55 +** <li> SQLITE_MUTEX_STATIC_MASTER
1.56 +** <li> SQLITE_MUTEX_STATIC_MEM
1.57 +** <li> SQLITE_MUTEX_STATIC_MEM2
1.58 +** <li> SQLITE_MUTEX_STATIC_PRNG
1.59 +** <li> SQLITE_MUTEX_STATIC_LRU
1.60 +** </ul>
1.61 +**
1.62 +** The first two constants cause sqlite3_mutex_alloc() to create
1.63 +** a new mutex. The new mutex is recursive when SQLITE_MUTEX_RECURSIVE
1.64 +** is used but not necessarily so when SQLITE_MUTEX_FAST is used.
1.65 +** The mutex implementation does not need to make a distinction
1.66 +** between SQLITE_MUTEX_RECURSIVE and SQLITE_MUTEX_FAST if it does
1.67 +** not want to. But SQLite will only request a recursive mutex in
1.68 +** cases where it really needs one. If a faster non-recursive mutex
1.69 +** implementation is available on the host platform, the mutex subsystem
1.70 +** might return such a mutex in response to SQLITE_MUTEX_FAST.
1.71 +**
1.72 +** The other allowed parameters to sqlite3_mutex_alloc() each return
1.73 +** a pointer to a static preexisting mutex. Three static mutexes are
1.74 +** used by the current version of SQLite. Future versions of SQLite
1.75 +** may add additional static mutexes. Static mutexes are for internal
1.76 +** use by SQLite only. Applications that use SQLite mutexes should
1.77 +** use only the dynamic mutexes returned by SQLITE_MUTEX_FAST or
1.78 +** SQLITE_MUTEX_RECURSIVE.
1.79 +**
1.80 +** Note that if one of the dynamic mutex parameters (SQLITE_MUTEX_FAST
1.81 +** or SQLITE_MUTEX_RECURSIVE) is used then sqlite3_mutex_alloc()
1.82 +** returns a different mutex on every call. But for the static
1.83 +** mutex types, the same mutex is returned on every call that has
1.84 +** the same type number.
1.85 +*/
1.86 +sqlite3_mutex *sqlite3_mutex_alloc(int iType){
1.87 + static sqlite3_mutex staticMutexes[] = {
1.88 + { PTHREAD_MUTEX_INITIALIZER, },
1.89 + { PTHREAD_MUTEX_INITIALIZER, },
1.90 + { PTHREAD_MUTEX_INITIALIZER, },
1.91 + { PTHREAD_MUTEX_INITIALIZER, },
1.92 + { PTHREAD_MUTEX_INITIALIZER, },
1.93 + };
1.94 + sqlite3_mutex *p;
1.95 + switch( iType ){
1.96 + case SQLITE_MUTEX_RECURSIVE: {
1.97 + p = sqlite3MallocZero( sizeof(*p) );
1.98 + if( p ){
1.99 + pthread_mutexattr_t recursiveAttr;
1.100 + pthread_mutexattr_init(&recursiveAttr);
1.101 + pthread_mutexattr_settype(&recursiveAttr, PTHREAD_MUTEX_RECURSIVE);
1.102 + pthread_mutex_init(&p->mutex, &recursiveAttr);
1.103 + pthread_mutexattr_destroy(&recursiveAttr);
1.104 + p->id = iType;
1.105 + }
1.106 + break;
1.107 + }
1.108 + case SQLITE_MUTEX_FAST: {
1.109 + p = sqlite3MallocZero( sizeof(*p) );
1.110 + if( p ){
1.111 + p->id = iType;
1.112 + pthread_mutex_init(&p->mutex, 0);
1.113 + }
1.114 + break;
1.115 + }
1.116 + default: {
1.117 + assert( iType-2 >= 0 );
1.118 + assert( iType-2 < sizeof(staticMutexes)/sizeof(staticMutexes[0]) );
1.119 + p = &staticMutexes[iType-2];
1.120 + p->id = iType;
1.121 + break;
1.122 + }
1.123 + }
1.124 + return p;
1.125 +}
1.126 +
1.127 +
1.128 +/*
1.129 +** This routine deallocates a previously
1.130 +** allocated mutex. SQLite is careful to deallocate every
1.131 +** mutex that it allocates.
1.132 +*/
1.133 +void sqlite3_mutex_free(sqlite3_mutex *p){
1.134 + assert( p );
1.135 + assert( p->nRef==0 );
1.136 + assert( p->id==SQLITE_MUTEX_FAST || p->id==SQLITE_MUTEX_RECURSIVE );
1.137 + pthread_mutex_destroy(&p->mutex);
1.138 + sqlite3_free(p);
1.139 +}
1.140 +
1.141 +/*
1.142 +** The sqlite3_mutex_enter() and sqlite3_mutex_try() routines attempt
1.143 +** to enter a mutex. If another thread is already within the mutex,
1.144 +** sqlite3_mutex_enter() will block and sqlite3_mutex_try() will return
1.145 +** SQLITE_BUSY. The sqlite3_mutex_try() interface returns SQLITE_OK
1.146 +** upon successful entry. Mutexes created using SQLITE_MUTEX_RECURSIVE can
1.147 +** be entered multiple times by the same thread. In such cases the,
1.148 +** mutex must be exited an equal number of times before another thread
1.149 +** can enter. If the same thread tries to enter any other kind of mutex
1.150 +** more than once, the behavior is undefined.
1.151 +*/
1.152 +void sqlite3_mutex_enter(sqlite3_mutex *p){
1.153 + assert( p );
1.154 + assert( p->id==SQLITE_MUTEX_RECURSIVE || sqlite3_mutex_notheld(p) );
1.155 + pthread_mutex_lock(&p->mutex);
1.156 + p->owner = pthread_self();
1.157 + p->nRef++;
1.158 +#ifdef SQLITE_DEBUG
1.159 + if( p->trace ){
1.160 + printf("enter mutex %p (%d) with nRef=%d\n", p, p->trace, p->nRef);
1.161 + }
1.162 +#endif
1.163 +}
1.164 +int sqlite3_mutex_try(sqlite3_mutex *p){
1.165 + int rc;
1.166 + assert( p );
1.167 + assert( p->id==SQLITE_MUTEX_RECURSIVE || sqlite3_mutex_notheld(p) );
1.168 + if( pthread_mutex_trylock(&p->mutex)==0 ){
1.169 + p->owner = pthread_self();
1.170 + p->nRef++;
1.171 + rc = SQLITE_OK;
1.172 +#ifdef SQLITE_DEBUG
1.173 + if( p->trace ){
1.174 + printf("enter mutex %p (%d) with nRef=%d\n", p, p->trace, p->nRef);
1.175 + }
1.176 +#endif
1.177 + }else{
1.178 + rc = SQLITE_BUSY;
1.179 + }
1.180 + return rc;
1.181 +}
1.182 +
1.183 +/*
1.184 +** The sqlite3_mutex_leave() routine exits a mutex that was
1.185 +** previously entered by the same thread. The behavior
1.186 +** is undefined if the mutex is not currently entered or
1.187 +** is not currently allocated. SQLite will never do either.
1.188 +*/
1.189 +void sqlite3_mutex_leave(sqlite3_mutex *p){
1.190 + assert( p );
1.191 + assert( sqlite3_mutex_held(p) );
1.192 + p->nRef--;
1.193 + assert( p->nRef==0 || p->id==SQLITE_MUTEX_RECURSIVE );
1.194 +#ifdef SQLITE_DEBUG
1.195 + if( p->trace ){
1.196 + printf("leave mutex %p (%d) with nRef=%d\n", p, p->trace, p->nRef);
1.197 + }
1.198 +#endif
1.199 + pthread_mutex_unlock(&p->mutex);
1.200 +}
1.201 +
1.202 +/*
1.203 +** The sqlite3_mutex_held() and sqlite3_mutex_notheld() routine are
1.204 +** intended for use only inside assert() statements. On some platforms,
1.205 +** there might be race conditions that can cause these routines to
1.206 +** deliver incorrect results. In particular, if pthread_equal() is
1.207 +** not an atomic operation, then these routines might delivery
1.208 +** incorrect results. On most platforms, pthread_equal() is a
1.209 +** comparison of two integers and is therefore atomic. But we are
1.210 +** told that HPUX is not such a platform. If so, then these routines
1.211 +** will not always work correctly on HPUX.
1.212 +**
1.213 +** On those platforms where pthread_equal() is not atomic, SQLite
1.214 +** should be compiled without -DSQLITE_DEBUG and with -DNDEBUG to
1.215 +** make sure no assert() statements are evaluated and hence these
1.216 +** routines are never called.
1.217 +*/
1.218 +#ifndef NDEBUG
1.219 +int sqlite3_mutex_held(sqlite3_mutex *p){
1.220 + return p==0 || (p->nRef!=0 && pthread_equal(p->owner, pthread_self()));
1.221 +}
1.222 +int sqlite3_mutex_notheld(sqlite3_mutex *p){
1.223 + return p==0 || p->nRef==0 || pthread_equal(p->owner, pthread_self())==0;
1.224 +}
1.225 +#endif
1.226 +#endif /* SQLITE_MUTEX_PTHREAD */
