Re: [ECOS] Nested calls to Mutexes

["Lewin A.R.W. Edwards" <larwe at larwe dot com>]

My $0.02:

> > I disagree with this statement. It is a *common idiom* to have
> > routines that needs to "lock" some access to start calling other
> > routines that "locks" the mutex again.
>
>To me this is dangerous. Mutex's are used to protect state
>information. I lock the mutex when im want to modify the state

Some time ago (actually, when I was programming the Commodore Amiga), I 
used a kind of "nested mutex" concept routinely by "protecting" things with 
an integer "lock count" variable. Something that wanted to grab the 
protected resource would increment the lock count; decrement to release. As 
long as the calls were balanced, a zero value in the lock count meant 
nobody owned the resource.

Since those early days, I have been severely and painfully bitten in the 
rear end by this technique more than once, and I am now fully in agreement 
with Andrew. The problems you will encounter range from "this code is now 
impossible to maintain" (because ten different functions all believe they 
own the protected item, and it's impossible to work out who really does own 
it and who really SHOULD own it) to customer complaints that "this code has 
random bugs in it that you never fix" (because interrupts are occasionally 
occurring at precisely the wrong time) and everything in between.

A mutex is the equivalent of posting a KEEP OUT sign. "Nested mutexes" are 
the equivalent of putting a note on the sign saying "but you can come in if 
you really want to".

You might be able to solve your particular issue by redesigning the code 
flow so that there is a single entry point that grabs the mutex and a 
single exit point that releases it. So, instead of having ten different 
functions that grab the mutex, do something to a data structure, then 
release the mutex, you could have a single function with an argument that 
indicates which of the ten different things you want to do.

Just because something is "common idiom" doesn't mean it's good design 
practice.

=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/

"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."