[webkit-dev] Expected behavior of Mutex.lock()
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
>> 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*
>> 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.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev