[webkit-dev] Expected behavior of Mutex.lock()

Jeremy Orlow jorlow at chromium.org
Tue Jun 16 20:30:40 PDT 2009

I'll post a bug and do this.  Shouldn't take long.

On Tue, Jun 16, 2009 at 8:23 PM, Maciej Stachowiak <mjs at apple.com> wrote:

> 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-entrant.
>> 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.
> Regards,
> Maciej
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090616/0d935891/attachment-0001.html>

More information about the webkit-dev mailing list