David Barbour wrote:
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.
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.
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().
Regards,
Dave
[1]
http://stackoverflow.com/questions/1988324/how-to-alter-the-recursive-locking-behaviour-of-windows-mutex
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
