[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [LMDB] inconsistent mutex behavior and problems for M:N threading

On 12/11/2014 02:21 AM, Howard Chu wrote:
David Barbour wrote:
When two writers operate in the same thread using M:N threading, a bug
will occur in Windows whenever two different lightweight 'writer'
threads grab the same mutex in the same OS thread. Because both writers
will succeed.

Yes - after the code which locks the write mutex, mdb.c should do:
    if (env->me_txn) {
        unlock the mutex;
        return MDB_DEADLOCK;
That also helps with MDB_NOLOCK.

Interesting. The downside of your semaphore suggestion on Windows is that
means any thread can also unlock it, regardless of current owner. This is
also detected as an error in POSIX mutexes.

If mdb.c uses error-checking mutexes
   pthread_mutexattr_settype(&mattr, PTHREAD_MUTEX_ERRORCHECK)
and checks for the error, yes:-)

OTOH, I can't spot a problem with write transactions being thread-
independent, as long as the user serializes the operations within
these transactions.

On the third hand, semaphores will block before it can get to the
env->me_txn error check above.

We could save the thread ID in the mdb_env and check it before locking,
but that could give false positives because thread IDs need not be

LMDB is documented to be a single-writer design. I don't see any sane way for
us to support M:N threading models ourselves; not portably to all the
possible runtimes out there. I suggest you wrap your own mutex mechanism
around your wrapper for mdb_txn_begin().