Re: [Xenomai-help] mutex locking

Re: [Xenomai-help] mutex locking

[Tobias Bär]

> Try this, it's safe from such races:
> 
> /* returns -EWOULDBLOCK if the mutex is locked */
> if (rt_mutex_lock(&write_mutex,TM_NONBLOCK) == 0)
> {
>       // do sth.
> 
>       rt_mutex_unlock(&mutex);
> }

Thank's for the quick reply! But another question: How could it be that a mutex is locked twice?

if(rt_mutex_lock(&write_mutex,TM_NONBLOCK) == 0)
  {
    if(rt_mutex_lock(&write_mutex,TM_NONBLOCK) == 0)
      printf("Mutex is locked twice!\n");

   rt_mutex_unlock(&mutex);
  }

Is it locked by the ID of the thread?

Tobias

Re: [Xenomai-help] mutex locking

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

Tobias Bär wrote:
>> -----Ursprüngliche Nachricht-----
>> Von: Jan Kiszka <jan.kiszka@domain.hid>
>> Gesendet: 21.06.06 11:46:34
>> An: Tobias Bär <Tobias.Baer@domain.hid>
>> CC: xenomai@xenomai.org
>> Betreff: Re: [Xenomai-help] mutex locking
> 
>> Try this, it's safe from such races:
>>
>> /* returns -EWOULDBLOCK if the mutex is locked */
>> if (rt_mutex_lock(&write_mutex,TM_NONBLOCK) == 0)
>> {
>>       // do sth.
>>
>>       rt_mutex_unlock(&mutex);
>> }
> 
> Thank's for the quick reply! But another question: How could it be that a mutex is locked twice?
> 

RTFM ;): "Xenomai mutexes are implicitely recursive [...]."

> if(rt_mutex_lock(&write_mutex,TM_NONBLOCK) == 0)
>   {
>     if(rt_mutex_lock(&write_mutex,TM_NONBLOCK) == 0)
>       printf("Mutex is locked twice!\n");
> 
>    rt_mutex_unlock(&mutex);
>   }
> 
> Is it locked by the ID of the thread?
> 

Yep, the owner is recorded, also to perform priority inheritance when
required. Recursive means that the current owner can acquire the mutex
multiple times (but (s)he also has to release it symmetrically then -
your example is lacking one unlock).

If you use the POSIX skin with its standard pthread_mutex'es, then you
can decide about the recursiveness explicitly.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

[Xenomai-help] mutex locking

[Tobias Bär]

Hi all,

my question is about the right way to lock and inquire a mutex. At time, my code looks like this:


rt_mutex_inquire(&mutex,TM_NONBLOCK);

if(info.lockcnt == 0) 
{
      rt_mutex_lock(&write_mutex,TM_NONBLOCK);

      // do sth.

      rt_mutex_unlock(&mutex);
}


What happens if anyone locks the mutex between my "rt_mutex_inquire(...)" and my "if(info.lockcnt == 0)" ?

Is this the standard way to lock and inquire a mutex?

Thanks,
  Tobias

Re: [Xenomai-help] mutex locking

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

Tobias Bär wrote:
> Hi all,
> 
> my question is about the right way to lock and inquire a mutex. At time, my code looks like this:
> 
> 
> rt_mutex_inquire(&mutex,TM_NONBLOCK);
> 
> if(info.lockcnt == 0) 
> {
>       rt_mutex_lock(&write_mutex,TM_NONBLOCK);
> 
>       // do sth.
> 
>       rt_mutex_unlock(&mutex);
> }
> 
> 
> What happens if anyone locks the mutex between my "rt_mutex_inquire(...)" and my "if(info.lockcnt == 0)" ?
> 
> Is this the standard way to lock and inquire a mutex?
> 

Try this, it's safe from such races:

/* returns -EWOULDBLOCK if the mutex is locked */
if (rt_mutex_lock(&write_mutex,TM_NONBLOCK) == 0)
{
      // do sth.

      rt_mutex_unlock(&mutex);
}

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-help] mutex locking

[Philippe Gerum]

On Wed, 2006-06-21 at 11:37 +0200, Tobias Bär wrote:
> Hi all,
> 
> my question is about the right way to lock and inquire a mutex. At time, my code looks like this:
> 
> 
> rt_mutex_inquire(&mutex,TM_NONBLOCK);
> 
> if(info.lockcnt == 0) 
> {
>       rt_mutex_lock(&write_mutex,TM_NONBLOCK);
> 
>       // do sth.
> 
>       rt_mutex_unlock(&mutex);
> }
> 
> 
> What happens if anyone locks the mutex between my "rt_mutex_inquire(...)" and my "if(info.lockcnt == 0)" ?
> 
> Is this the standard way to lock and inquire a mutex?

No, this snippet is terminally broken, I'm afraid. The mutex object is
precisely aimed at avoiding this kind of race conditions; the code above
would introduce them back.

Native skin mutexes are recursive by nature, so there is no need to
inquire for their current status. Additionally, passing TM_NONBLOCK
might cause mutex_lock() to return an error, if another thread holds it
already, so you need to check for the return value in any case. What you
likely want is, either:

if (rt_mutex_lock(...TM_INFINITE) < 0)
	bail_out();
/* work in critical section */
rt_mutex_unlock()

or,

if (rt_mutex_lock(...TM_NONBLOCK) < 0)
	resource_not_immediately_available();
/* work in critical section */
rt_mutex_unlock()


> 
> Thanks,
>   Tobias
> 
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
-- 
Philippe.