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

[Dmitry Titov]

Then perhaps all implementations could ASSERT in debug on mutex reentrancy
to help discover where differences in behavior are accidentally 'used' (a
stuck thread may sometimes mask some other issues).

It's not good to have this kind of differences in 'cross-platform' code,
sooner or later it'll cause very cryptic bugs, especially since developers
with Windows background take reentrancy of critical section for granted.

Dmitry

On Tue, Jun 9, 2009 at 11:34 AM, Jeremy Orlow <jorlow at chromium.org> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/20090611/39b7abfc/attachment.html>