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

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



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.

Regards,

Dave

[1] http://stackoverflow.com/questions/1988324/how-to-alter-the-recursive-locking-behaviour-of-windows-mutex