[webkit-dev] Expected behavior of Mutex.lock()
mjs at apple.com
Tue Jun 16 20:23:06 PDT 2009
On Jun 6, 2009, at 8:57 AM, Drew Wilson wrote:
> I can't seem to find any documentation as to what the expected
> behavior of Mutex.lock() is with regard to calling lock()
> recursively on the same thread.
> Looking at the pthreads implementation, it appears that when we
> create the mutex we pass null as the attributes, which gives us the
> default behavior (not re-entrant).
> The Windows implementation uses EnterCriticalSection which *is* re-
> I'm assuming that the pthreads implementation is the correct one
> (calling Mutex.lock() twice on the same mutex on a single thread
> should deadlock the thread) but I wanted to verify this since the
> implementations seem to vary.
The way I would put it is: Mutex.lock() cannot safely be called by a
thread already holding the lock. I don't think it makes the
implementation "wrong" to allow this to work. But it's true that this
could lead developers astray if they only test on platforms where the
implementation of Mutex happens to be reentrant. Thus, it would be a
good idea to document the fact that reentrancy is not guaranteed, and
add ASSERTs to try to check that it is not relied upon.
More information about the webkit-dev