[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANNOUNCE]: LuaThreads 1.0-work, pre-release
- From: Diego Fernandes Nehab <diego@...>
- Date: Thu, 13 Dec 2001 01:30:13 -0200 (BRST)
> If the caller thread is already the owner of the mutex, nothing happens.
> If it owned by the caller thread, it is switched to the unlocked state.
> - Does this imply that mutex locks do not correctly nest? If so I think
> it would be extremely beneficial (and far less error prone) if they were
> made to do so.
Sorry about that. I made a confusion with this. The manual is wrong. The
way it is now, mutex:lock() on a owned mutex will dead-lock on Unix and
nest on Win32.
I remember reading that recursive mutexes (those that nest) can not be
used with condition variables in some pthread implementations, and
that's why I chose the fast (and default) ones. Also, I think they are
not portable. I will check on that, but I don't think it would be worth
it to implement them by hand for performance reasons.
In the Win32, I am using critical sections because they are faster. And
they happen to nest... And so do Win32 mutexes.
I will think about the direction to follow, but I don't think relocking
a mutex is good practice. Meanwhile, I will correct the manual, saying
the behavior is unspecified.