[ECOS] reentrant mutex

[ECOS] reentrant mutex

[mark_lee_hamilton]

Will reentrant mutex support be added in the near future? I ask because this 
functionality is currently missing in 2.0 beta. I scanned through the email 
archives and noticed that topic was brought up a while back. There didn't seem 
to be much of a desire to support a reentrant mutex. I'm hoping that there has 
been a change of heart on the topic. 
Does someone have a patch?

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] reentrant mutex

[Mark Hamilton]

Gentleman,
 See comments below.
----- Original Message -----
From: "Nick Garnett" <nickg@ecoscentric.com>
To: "Jonathan Larmour" <jifl@eCosCentric.com>
Cc: <mark_lee_hamilton@att.net>; "ecos" <ecos-discuss@sources.redhat.com>
Sent: Monday, April 14, 2003 2:50 AM
Subject: Re: [ECOS] reentrant mutex


> Jonathan Larmour <jifl@eCosCentric.com> writes:
>
> > mark_lee_hamilton@att.net wrote:
> > > Will reentrant mutex support be added in the near future? I ask
> > > because this functionality is currently missing in 2.0 beta. I
> > > scanned through the email archives and noticed that topic was
> > > brought up a while back. There didn't seem to be much of a desire to
> > > support a reentrant mutex. I'm hoping that there has been a change
> > > of heart on the topic.
> >
> > I think it's unlikely we'd want to make existing mutexes recursive,
> > but as indeed one of the threads in the past mentioned, some separate
> > recursive mutex type could be added.
> >
> > Whether or not "strategically" such a patch would be accepted in the
> > sources I'll leave to Nick G though. Personally I'm keen as the kernel
> > is meant to be more than just basic primitives, but a box of tools to
> > make development easier.
> >
>
> I would personally not like to see such a patch. It would not work
> very well with condition variables and any system that mixed regular
> and recursive mutexes would be very hard to debug.
>
> In my opinion, a need for recursive mutexes is usually a symptom of
> poor program design.
Oh, now you've hurt my honor. I think recursive mutexes have their place.
I'll simply point out that W2K and up, Solaris, IRIX, HP's OS, WinCE,
VxWorks, ThreadX, pSOS and AMX all support recursive mutexes. These are just
the ones that I've dealt with. I'm guessing that you would be hard pressed
to find and RTOS that doesn't support recursive mutexes - oh except for
eCos.

There is also the issue of POSIX compliants. Without recursive mutexes is
eCos really POSIX compliant.

As for any future design, I would strongly discourage having two types of
mutexes exposed to developers. I would prefer that two additional functions
be added to the existing API: cyg_mutex_set_type and cyg_mutex_get_type.
Having two types of mutexes is annoying for the developer. If I start with
non-recursive mutexes and then switch to recursive I would have to modify my
code in many places. Verses just calling cyg_mutex_type_set(RECURSIVE) after
the creation of a mutex.

As for justifing their existance. I find that I normally use them to
implement a Monitor, a class where accessor methods guard a critical region
of private attributes. With recursive mutexes public methods can call other
public methods. Without recursive mutexes, I have to create additional
private methods that do not lock mutexes.
Besides a mutex's responsibility is to prevent multiple threads from
accessing a critical region. Recursive support does not break that paradigm.
It only provides the possibility of simplier code.

I'm by no means an expert on the eCos implementation. It seems that the code
snippet below would fit nicely inside of Cyg_Mutex::lock(void).
while( locked && result )
    {
        //Replace CYG_ASSERT with the recursive support.
       //CYG_ASSERT( self != owner, "Locking mutex I already own");
        if((type == RECURSIVE) && (cyg_thread_self() == mx->owner ))
        {
           count++;
           Cyg_Scheduler::unlock();
           return;
         }
        else
        {
          CYG_ASSERT( self != owner, "Locking mutex I already own");
        }

        self->set_sleep_reason( Cyg_Thread::WAIT );

        self->sleep();

        queue.enqueue( self );

You could simple state that by default mutexes are not-recursive. Therefore
all existing kernel code would not change. Users who want recursive mutexes
would need to call cyg_mutex_set_type(cyg_handle_t, int type). As for your
concern with conditional variables, maybe a comment in the documentation
explaining the reasons against using recursive mutexes with conditional
variables would suffice.

>
> If anybody really wants recursive mutexes, then they can always
> implement them above the existing mutex mechanism. For example:
>
> typedef struct
> {
>     cyg_mutex_t     mutex;
>     cyg_handle_t    owner;
>     cyg_uint32      count;
> } cyg_recursive_mutex;
>
> void cyg_recursive_mutex_lock( cyg_recursive_mutex *mx )
> {
>     cyg_scheduler_lock();
>     {
>         if( cyg_thread_self() == mx->owner )
>         {
>             mx->count++;
>         }
>         else
>         {
>             cyg_mutex_lock( &mx->mutex );
>             mx->count = 1;
>             mx->owner = cyg_thread_self();
>         }
>     }
>     cyg_scheduler_unlock();
> }
>
> The rest is left as an exercise for the reader.
>
> --
> Nick Garnett                    eCos Kernel Architect
> http://www.ecoscentric.com/     The eCos and RedBoot experts
>


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] reentrant mutex

[Jonathan Larmour]

Nick Garnett wrote:
> Jonathan Larmour <jifl@eCosCentric.com> writes:
> 
> 
>>Nick Garnett wrote:
>>
>>>I would personally not like to see such a patch. It would not work
>>>very well with condition variables and any system that mixed regular
>>>and recursive mutexes would be very hard to debug.
>>
>>I'm not sure it would make that much difference since they would be
>>completely different types... I would agree that making a Cyg_Mutex
>>have configurable behaviour would be bad and confusing. Similarly
>>therefore, since condvars only take a Cyg_Mutex and not a
>>Cyg_Recursive_Mutex (or whatever), it should be fine.
> 
> 
> Mutexes without condition variables are not very useful. The two are
> complimentary parts of a single synchronization mechanism. Taking the
> patch idea to its logical conclusion, we would also need a set of
> condition variables that took a recursive mutex. We would end up with
> two independent parallel synchonization domains. That would be a
> really nasty can of worms to open.

What, like cnt_sem and cnt_sem2 (or even bin_sem for that matter since 
that isn't in the kapi) ;-). Ditto mboxt and mboxt2.

I don't think having two (semantically different and differently named) 
primitives is a problem. The two cond vars could even share code easily 
enough, so it wouldn't cause any significant maintenance issue.

>>Anyway, I just want to be sure that defining a recursive mutex as a
>>completely different type would still not be acceptable.
> 
> I suspect that the only way of doing it is to add a runtime option to
> the mutex implementation to support recursion. However this would
> require some of the API to change and would need an
> up-to-the-elbows-in-blood-and-guts rewrite of the mutex and condition
> variable code, as well as lots of other bits of eCos. The degree of
> instability this would introduce is probably not worth it for a
> relatively minor change in external functionality.

I agree. If it should be done at all, it should be with a separate type.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] reentrant mutex

[Nick Garnett]

Jonathan Larmour <jifl@eCosCentric.com> writes:

> Nick Garnett wrote:
> > I would personally not like to see such a patch. It would not work
> > very well with condition variables and any system that mixed regular
> > and recursive mutexes would be very hard to debug.
> 
> I'm not sure it would make that much difference since they would be
> completely different types... I would agree that making a Cyg_Mutex
> have configurable behaviour would be bad and confusing. Similarly
> therefore, since condvars only take a Cyg_Mutex and not a
> Cyg_Recursive_Mutex (or whatever), it should be fine.

Mutexes without condition variables are not very useful. The two are
complimentary parts of a single synchronization mechanism. Taking the
patch idea to its logical conclusion, we would also need a set of
condition variables that took a recursive mutex. We would end up with
two independent parallel synchonization domains. That would be a
really nasty can of worms to open.

> 
> Anyway, I just want to be sure that defining a recursive mutex as a
> completely different type would still not be acceptable.
> 

I suspect that the only way of doing it is to add a runtime option to
the mutex implementation to support recursion. However this would
require some of the API to change and would need an
up-to-the-elbows-in-blood-and-guts rewrite of the mutex and condition
variable code, as well as lots of other bits of eCos. The degree of
instability this would introduce is probably not worth it for a
relatively minor change in external functionality.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] reentrant mutex

[Jonathan Larmour]

Nick Garnett wrote:
> Jonathan Larmour <jifl@eCosCentric.com> writes:
>>Whether or not "strategically" such a patch would be accepted in the
>>sources I'll leave to Nick G though. Personally I'm keen as the kernel
>>is meant to be more than just basic primitives, but a box of tools to
>>make development easier.
>>
> 
> 
> I would personally not like to see such a patch. It would not work
> very well with condition variables and any system that mixed regular
> and recursive mutexes would be very hard to debug. 

I'm not sure it would make that much difference since they would be 
completely different types... I would agree that making a Cyg_Mutex have 
configurable behaviour would be bad and confusing. Similarly therefore, 
since condvars only take a Cyg_Mutex and not a Cyg_Recursive_Mutex (or 
whatever), it should be fine.

> In my opinion, a need for recursive mutexes is usually a symptom of
> poor program design. 

I'm not sure it's up to us to decide. And getting people to write more 
code each time means more scope for errors on their part, whereas we can 
be sure to have one that is well tested.

> If anybody really wants recursive mutexes, then they can always
> implement them above the existing mutex mechanism. For example:

We could say that about much of the kernel :-).

Anyway, I just want to be sure that defining a recursive mutex as a 
completely different type would still not be acceptable.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] reentrant mutex

[Nick Garnett]

Jonathan Larmour <jifl@eCosCentric.com> writes:

> mark_lee_hamilton@att.net wrote:
> > Will reentrant mutex support be added in the near future? I ask
> > because this functionality is currently missing in 2.0 beta. I
> > scanned through the email archives and noticed that topic was
> > brought up a while back. There didn't seem to be much of a desire to
> > support a reentrant mutex. I'm hoping that there has been a change
> > of heart on the topic.
> 
> I think it's unlikely we'd want to make existing mutexes recursive,
> but as indeed one of the threads in the past mentioned, some separate
> recursive mutex type could be added.
> 
> Whether or not "strategically" such a patch would be accepted in the
> sources I'll leave to Nick G though. Personally I'm keen as the kernel
> is meant to be more than just basic primitives, but a box of tools to
> make development easier.
> 

I would personally not like to see such a patch. It would not work
very well with condition variables and any system that mixed regular
and recursive mutexes would be very hard to debug. 

In my opinion, a need for recursive mutexes is usually a symptom of
poor program design. 

If anybody really wants recursive mutexes, then they can always
implement them above the existing mutex mechanism. For example:

typedef struct 
{
    cyg_mutex_t     mutex;
    cyg_handle_t    owner;
    cyg_uint32      count;
} cyg_recursive_mutex;

void cyg_recursive_mutex_lock( cyg_recursive_mutex *mx )
{
    cyg_scheduler_lock();
    {
        if( cyg_thread_self() == mx->owner )
        {
            mx->count++;
        }
        else
        {
            cyg_mutex_lock( &mx->mutex );
            mx->count = 1;
            mx->owner = cyg_thread_self();
        }
    }
    cyg_scheduler_unlock();
}

The rest is left as an exercise for the reader.

-- 
Nick Garnett                    eCos Kernel Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] reentrant mutex

[Jonathan Larmour]

mark_lee_hamilton@att.net wrote:
> Will reentrant mutex support be added in the near future? I ask because this 
> functionality is currently missing in 2.0 beta. I scanned through the email 
> archives and noticed that topic was brought up a while back. There didn't seem 
> to be much of a desire to support a reentrant mutex. I'm hoping that there has 
> been a change of heart on the topic. 

I think it's unlikely we'd want to make existing mutexes recursive, but as 
indeed one of the threads in the past mentioned, some separate recursive 
mutex type could be added.

Whether or not "strategically" such a patch would be accepted in the 
sources I'll leave to Nick G though. Personally I'm keen as the kernel is 
meant to be more than just basic primitives, but a box of tools to make 
development easier.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] Reentrant Mutex

[Bart Veer]

>>>>> "Fabrice" == Fabrice Gautier <Fabrice_Gautier@sdesigns.com> writes:

    Fabrice> I would like to have a reentrant mutex structure. Do you
    Fabrice> think there will have one someday in eCos ?

This came up on ecos-discuss a little while back, see
http://sources.redhat.com/ml/ecos-discuss/2000-06/msg00333.html

As far as I am concerned the standard eCos kernel mutexes are unlikely
ever to support recursive locking, partly because of the overheads
involved and partly because the whole concept of a recursive mutex is
flawed.

As reported by Boris, it is relatively straightforward to implement
recursive mutexes using the primitives provided by eCos. The kernel
could support such recursive mutexes via a separate C++ class plus
matching C API functions, as opposed to overloading the existing mutex
support, but that would be a decision for the kernel folks.

Bart Veer // eCos net maintainer

Re: [ECOS] Reentrant Mutex

[Boris V. Guzhov]

> Hi,
>
> I would like to have a reentrant mutex structure. Do you think there will
> have one someday in eCos ?
>
> Thanks
>
> --
> Fabrice Gautier

Hi,

In eCos I not find the reentrant (or recursive) mutex's.
I did following additional to eCos code:

/* Mutex type */
#define MUTEX_NORMAL       0
#define MUTEX_RECURSIVE    1

/* Mutexes */
typedef struct
{
  cyg_mutex_t m_em;       /* ecos mutex */
  int m_type;                     /*  mutex type */
  int m_lock;                     /* lock mutex deep */
} mutex_t;

int mutex_init(mutex_t *mutex,  int type)
{
  if ( !mutex )
    return EINVAL;
  cyg_scheduler_lock();
  mutex->m_type = type;
  mutex->m_lock = 0;
  cyg_mutex_init(&mutex->m_em);
  cyg_scheduler_unlock();
  return 0;
}

int mutex_destroy ( mutex_t *mutex )
{
  cyg_scheduler_lock();
  if ( mutex->m_em.locked )
  {
    cyg_scheduler_unlock();
    return BUSY;
  }
  cyg_mutex_destroy(&mutex->m_em);
  cyg_scheduler_unlock();
  return 0;
}

int mutex_lock ( mutex_t *mutex )
{
  if ( !mutex )
    return EINVAL;
 cyg_scheduler_lock();
 if ( mutex->m_em.locked == 0 || mutex->m_em.owner != (cyg_thread
*)cyg_thread_self())
  {
    cyg_scheduler_unlock();
    cyg_mutex_lock(&mutex->m_em);
    cyg_scheduler_lock();
    mutex->m_lock = mutex->m_em.locked != 0;
    cyg_scheduler_unlock();
    return 0;
  }
  if (mutex->m_type == MUTEX_RECURSIVE )
  {
    mutex->m_lock++;
    cyg_scheduler_unlock();
    return 0;
  }
  cyg_scheduler_unlock();
  return EDEADLK;   /*  deadlock */
}

int mutex_unlock (mutex_t *mutex )
{
  if ( !mutex )
    return EINVAL;
 cyg_scheduler_lock();

 if ( !mutex->m_em.locked || mutex->m_em.owner != (cyg_thread
*)cyg_thread_self() )
  {
    cyg_scheduler_unlock();
    return EPERM;
  }
  if ( mutex->m_type == MUTEX_RECURSIVE )
  {
    mutex->m_lock--;
    if (mutex->m_lock)
    {
      cyg_scheduler_unlock();
      return 0;
    }
  }
  else
    mutex->m_lock = 0;
  cyg_scheduler_unlock();
  cyg_mutex_unlock(&mutex->m_em);
  return 0;
}

[ECOS] Reentrant Mutex

[Fabrice Gautier]

Hi,

I would like to have a reentrant mutex structure. Do you think there will
have one someday in eCos ?

Thanks

-- 
Fabrice Gautier
fabrice_gautier@sdesigns.com