Re: [ECOS] Nested calls to Mutexes

Re: [ECOS] Nested calls to Mutexes

[Rosimildo daSilva]

>From: martin@fatbob.nu
>
>Well, this isn't entirely true. The default behaviour is as you describe, 
>but
>this can be changed using pthread_mutexattr_setkind_np(attr, kind)
>where kind can take the value PTHREAD_MUTEX_RECURSIVE_NP to create 
>recursive
>mutexes (reading from the man page for pthread_mutexattr_setkind_np(3)
>contained in glibc 2.2).
>I've run across this before, but it's easy to solve using some wrapper
>function to create recursive mutexes.
>
>Regards
>/Martin
>

Thanks Martin. This is very useful information.

Rosimildo.



_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: [ECOS] Nested calls to Mutexes

[Jonathan Larmour]

martin@fatbob.nu wrote:
> 
> On Thu, Mar 22, 2001 at 04:46:30PM +0000, Jonathan Larmour wrote:
> 
> > [ Sent this yesterday but it bounced! ]
> >
> > Rosimildo daSilva wrote:
> > >
> > > 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*.
> >
> > POSIX doesn't. Quite the opposite in fact, and that's hardly an obscure
> > standard....
> > "An attempt by the current owner of a mutex to relock the mutex results in
> > undefined behavior".
> 
> Well, this isn't entirely true. The default behaviour is as you describe, but
> this can be changed using pthread_mutexattr_setkind_np(attr, kind)
> where kind can take the value PTHREAD_MUTEX_RECURSIVE_NP to create recursive
> mutexes (reading from the man page for pthread_mutexattr_setkind_np(3)
> contained in glibc 2.2).

pthread_mutexattr_setkind_np() is not a POSIX function. It's purely a glibc
extension.

> I've run across this before, but it's easy to solve using some wrapper
> function to create recursive mutexes.

Quite.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] Nested calls to Mutexes

[martin]

On Thu, Mar 22, 2001 at 04:46:30PM +0000, Jonathan Larmour wrote:

> [ Sent this yesterday but it bounced! ]
> 
> Rosimildo daSilva wrote:
> > 
> > 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*.
> 
> POSIX doesn't. Quite the opposite in fact, and that's hardly an obscure
> standard....
> "An attempt by the current owner of a mutex to relock the mutex results in
> undefined behavior".

Well, this isn't entirely true. The default behaviour is as you describe, but
this can be changed using pthread_mutexattr_setkind_np(attr, kind)
where kind can take the value PTHREAD_MUTEX_RECURSIVE_NP to create recursive
mutexes (reading from the man page for pthread_mutexattr_setkind_np(3)
contained in glibc 2.2).
I've run across this before, but it's easy to solve using some wrapper
function to create recursive mutexes.

Regards
/Martin

> 
> And "undefined behavior" means anything from the recursive mutexes you want
> to contacting NORAD with the missile codes to start World War III.
> 
> So don't do this, the world is in your hands. :-)
> 
> Jifl
> -- 
> Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
> Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
> 

Re: [ECOS] Nested calls to Mutexes

[Jonathan Larmour]

[ Sent this yesterday but it bounced! ]

Rosimildo daSilva wrote:
> 
> 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*.

POSIX doesn't. Quite the opposite in fact, and that's hardly an obscure
standard....
"An attempt by the current owner of a mutex to relock the mutex results in
undefined behavior".

And "undefined behavior" means anything from the recursive mutexes you want
to contacting NORAD with the missile codes to start World War III.

So don't do this, the world is in your hands. :-)

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] Nested calls to Mutexes

[Rosimildo daSilva]

>From: Andrew Lunn <andrew.lunn@ascom.ch>
>To: eCos Disuss <ecos-discuss@sourceware.cygnus.com>
>Subject: Re: [ECOS] Nested calls to Mutexes
>Date: Wed, 21 Mar 2001 14:59:08 +0100
>To me this is dangerous. Mutex's are used to protect state
>information. I lock the mutex when im want to modify the state
>information. The locked mutex indicates the state information may not
>be consitent.

I am NOT going to argue with you. I believe that implementations
such as WIN32, OS/2, pSOS, RTEMS and many other OS provides have
a better semantic that the one that eCOs provides.

As long as the mutexes primitives guarantee that the mutex
still owned by the calling thread until all acquire()/release()
balance, I fail to see how this is dangerous.

If you plan to write code that must run on many platforms,
or at least you plan test a *fair amount* of your code on
platforms such as Lunix/Windows, it is nice to have the
mutex with the same behavior ( semantic ) of all OS's.
eCOs does not provide that for me, and I have to that
semantic to my code myself, possibly introducing errors.

Look at the behavior of the "synchronized" keyword of
java. It allows nested calls. There is no dangerous
doing this.

Show me a case where this behavior is dangerous ?

Rosimildo.








_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: [ECOS] Nested calls to Mutexes

[Lewin A.R.W. Edwards]

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."

Re: [ECOS] Nested calls to Mutexes

[Andrew Lunn]

> 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
information. The locked mutex indicates the state information may not
be consitent. 

Now you want the thread that locked the mutex to be able to call other
functions that also want to modify the state information. Those
functions have to be aware the state information could be
inconsitent. It cannot trust the information. Any changes it makes
could also make the other function which locked the mutex also go
wrong. 

You strongly tie the two functions together. Unless you know that this
is happening its very easy to make a mistake and create subtle bugs
which are hard to track down.

I say eCos is correct. It should throw an assertion when this
happens. I then know i have this sort of relationship going on and i
need to redesign my code,

If you do want the opertunity to shoot yourself in the foot, you could
modify your local copy of eCos. You have the source!

        Andrew

Re: [ECOS] Nested calls to Mutexes

[Rosimildo daSilva]

>From: Bart Veer Reply-To: bartv@redhat.com To: rosimildo@hotmail.com CC: 
>ecos-discuss@sourceware.cygnus.com Subject: Re: [ECOS] Nested calls to 
>Mutexes Date: Wed, 21 Mar 2001 13:29:28 GMT
>
>
>This issue has been raised before. See e.g. 
> http://sources.redhat.com/ml/ecos-discuss/2000-06/msg00333.html and 
> http://sources.redhat.com/ml/ecos-discuss/2000-08/msg00061.html
>
>There are no plans to change eCos' behaviour in this respect.


Thanks.

Fair enough. I guess I have to add some wrapper class
to extend the Mutex behavior a bit, on my project.

Rosimildo.




_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Re: [ECOS] Nested calls to Mutexes

[Jonathan Larmour]

Rosimildo daSilva wrote:
> 
> 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*.

POSIX doesn't. Quite the opposite in fact, and that's hardly an obscure
standard....
"An attempt by the current owner of a mutex to relock the mutex results in
undefined behavior".

And "undefined behavior" means anything from the recursive mutexes you want
to contacting NORAD with the missile codes to start World War III.

So don't do this, the world is in your hands. :-)

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] Nested calls to Mutexes

[Bart Veer]

>>>>> "Rosimildo" == Rosimildo daSilva <rosimildo@hotmail.com> writes:

    Rosimildo> Hi, the project I am working on, we have faced a small problem
    Rosimildo> with mutexes.

    >> From ecos documentation:

    Rosimildo> "When a thread locks a mutex it becomes the owner. Only
    Rosimildo> the mutex's owner may unlock it. While a mutex remains
    Rosimildo> locked, the owner should not lock it again, as the
    Rosimildo> behavior is undefined and probably dangerous. "

    Rosimildo> I disagree with this statement. It is a *common idiom*
    Rosimildo> to have routines that needs to "lock" some access to
    Rosimildo> start calling other routines that "locks" the mutex
    Rosimildo> again. In any sizeable project, this happens
    Rosimildo> eventually. As long as the acquire()/release() calls
    Rosimildo> are balanced, it should be no problem.

This issue has been raised before. See e.g.
http://sources.redhat.com/ml/ecos-discuss/2000-06/msg00333.html
and
http://sources.redhat.com/ml/ecos-discuss/2000-08/msg00061.html

There are no plans to change eCos' behaviour in this respect.

Bart

[ECOS] Nested calls to Mutexes

[Rosimildo daSilva]

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