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 [1].
I would like to hear other opinions on this matter.