The code setting up the locks is `mdb_env_setup_locks` circa line 4250 of
mdb.c. This code has a bunch of #ifdefs for posix vs win32. A major
difference is that locks for posix are non-recursive by default (unless you
set a specific flag), whereas the CreateMutex operation used for win32
creates recursive locks.
The MDB_NOTLS flag only affects readers.
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.
Conversely, in posix systems, a different bug will occur: the second writer
will attempt to grab the mutex; this will lock up the thread... which,
unfortunately, happens to be the same thread that the first writer needs to
use to unlock the mutex. There is no way for a lightweight writer to
migrate to another thread and unlock it there.
I believe both systems would behave more consistently and usefully if we
switch from mutexes to semaphores (of size 1). The difference is that a
semaphore doesn't track an 'owner' thread. This is also the suggestion to
avoid the recursive mutex behavior of windows .
I would like to hear other opinions on this matter.