bdb thread safety in tcl

I'm running into what I think is a thread safety issue under the tcl
interface to berkeleydb.

I made a very simple web page in aolserver (which is multithreaded)
which does this:

set db [berkdb open /tmp/test.bdb test]
puts [$db count x]
$db close

It works fine, except under high load, when the "$db count" command
gives

"NULL db info pointer"

Looking at the docs, I'm not seeing a way to enable multithreading from
the tcl interface. And looking at the C source, it seems that
something is very wrong if this db info pointer is missing.

So... questions:
1) is the tcl bdb interface thread safe, assuming no data sharing
between threads (ie, the code example above)
2) do I need to wrap all my bdb code with semaphores, and if so, will
that work?

-john

This comment in tcl_db_pkg.c sounds bad:
/*
* If/when our Tcl interface becomes thread-safe, we should enable
* DB_THREAD here in all cases. For now, we turn it on later in this
* function, and only when we're in testing and we specify the
* -thread flag, so that we can exercise MUTEX_THREAD_LOCK cases.
*
* In order to become truly thread-safe, we need to look at making sure
* DBTCL_INFO structs are safe to share across threads (they're not
* mutex-protected) before we declare the Tcl interface thread-safe.
* Meanwhile, there's no strong reason to enable DB_THREAD when not
* testing.
*/

john (AT) magnatune (DOT) com wrote:

I'm running into what I think is a thread safety issue under the tcl
interface to berkeleydb.

The Tcl API is not thread-safe right now. I reviewed the documentation
and have
submitted changes to state that clearly.

set db [berkdb open /tmp/test.bdb test]
puts [$db count x]
$db close

It works fine, except under high load, when the "$db count" command
gives
"NULL db info pointer"

That would be the expected error when threads race to modify the
global list of command handles created. If they both modify the next
pointer, one wins, one loses.

Looking at the docs, I'm not seeing a way to enable multithreading from
the tcl interface. And looking at the C source, it seems that
something is very wrong if this db info pointer is missing.

So... questions:
1) is the tcl bdb interface thread safe, assuming no data sharing
between threads (ie, the code example above)

No.

2) do I need to wrap all my bdb code with semaphores, and if so, will
that work?

Yes, that should work. That would serialize access to the underlying
global list of handles.

Sue LoVerso
Berkeley DB Group/ Oracle Corp.

2) do I need to wrap all my bdb code with semaphores, and if so, will
that work?
Yes, that should work. That would serialize access to the underlying
global list of handles.

FYI, mutexes around bdb calls doesn't seem to solve the thread-safety
problem. I tried both AOLServer's mutexes in Tcl and also patching the
bdb-tcl C code library with Tcl's -mutexes (ie,
Tcl_MutexLock(&myMutex); from
http://sourceforge.net/docman/displa...group_id=10894)
and still get the "NULL db info pointer" error in a multithreaded
settings.

Perhaps the bdb-tcl library is using thread-local storage or something
else which makes it not work in a multithreaded environ?

-john