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

[Hallvard Breien Furuseth <h.b.furuseth@usit.uio.no>]

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
atomic-sized.

> 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().

--
Hallvard