This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Nested calls to Mutexes
- To: ecos-discuss at sourceware dot cygnus dot com
- Subject: [ECOS] Nested calls to Mutexes
- From: "Rosimildo daSilva" <rosimildo at hotmail dot com>
- Date: Wed, 21 Mar 2001 07:18:07 -0600
Hi, the project I am working on, we have faced a small problem
with mutexes.
>From ecos documentation:
"When a thread locks a mutex it becomes the owner. Only the mutex's
owner
may unlock it. While a mutex remains locked, the owner should not lock
it
again, as the behavior is undefined and probably dangerous. "
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.
In any sizeable project, this happens eventually.
As long as the acquire()/release() calls are balanced,
it should be no problem.
class A
{
public:
void setData()
{
m.lock();
// set some important data
m.unlock();
}
void anotherMehod()
{
m.lock();
// do some atomic operations here.
if( ok )
{
setData();
}
// continue atomic operation
m.unlock();
}
private:
Mutex m;
}
Many implementations out there support the concept of
nested/balanced mutex calls. That is the programmer's
expectation. Sorry, to put this way, but I consider
this a *bug*.
Rosimildo.
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com