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

[Jeremy Orlow]

I actually had exact the same question (but never got around to asking it).

Given that pthreads' implementation is more strict, it'd seem like mutexes
are not supposed to be reentrant.  Maybe the windows version should ASSERT
on reentrancy when in debug mode?


On Tue, Jun 9, 2009 at 11:09 AM, Drew Wilson <atwilson at google.com> wrote:

> Any insights here? I'd be happy to add some documentation to Mutex if
> someone can verify what the intended behavior is...
> -atw "sending emails to webkit-dev during WWDC is probably futile, I know
> :)"
>
>
> On Sat, Jun 6, 2009 at 8:57 AM, Drew Wilson <atwilson at google.com> 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.
>>
>> -atw
>>
>
>
> _______________________________________________
> 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/20090609/1347937a/attachment.html>