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

[Jeremy Orlow]

Agreed the ASSERT needn't be Windows only.
It's probably better to ASSERT rather than deadlock on platforms without
reentrant implementations.  :-)

I'll file a bug for this (and might just fix it) in a couple days if there
are no more comments.

J

On Thu, Jun 11, 2009 at 10:39 AM, Dmitry Titov <dimich at chromium.org> wrote:

> 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/41866d66/attachment.html>