Re: [ANNOUNCE]: LuaThreads 1.0-work, pre-release

["Peter Loveday" <peter@...>]

Thanks for clearing this up.

While in simple cases re-locking a mutex might not be good practice, in
complex applications or where trying to extend existing functionality
it can be a nightmare if you must be aware of all locks performed by
any functions you call so as not to cause a lock twice.

For example, a List 'object' may lock itself in an RemoveItem() method,
to allow it to update internal state information safely; however if I now
want to write a method that can, say, filter items from the list based
on a pattern, ideally that method would lock the list while performing
the filter, so as to prevent other threads from changing the list during
the process. However, this means in that the filter method cannot use
the List's Remove method, so there would need to be a non-locking Remove()
for it to use, and a wrapper for something that does not have a lock to
use.

This can make design of larger scale systems difficult, at best, and
the problem is only worse when dealing with other people's libraries.
Basically short of searching the source code (if you have it), you
really must assume that it is not safe to call a function that affects
an object protected by a mutex you currently hold; which goes against
the idea of the mutex in the first place.

 
Love, Light and Peace,
- Peter Loveday
eyeon Software


----- Original Message ----- 
From: "Diego Fernandes Nehab" <diego@tecgraf.puc-rio.br>
To: "Multiple recipients of list" <lua-l@tecgraf.puc-rio.br>
Sent: Thursday, December 13, 2001 2:00 PM
Subject: Re: [ANNOUNCE]: LuaThreads 1.0-work, pre-release


> Hi,
> 
> > [mutex:lock()]
> > If the caller thread is already the owner of the mutex, nothing happens. 
> > [mutex:unlock()]
> > 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.
> 
> Regards,
> Diego.
> 
>