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

[Jeremy Orlow]

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>