[Xenomai-help] Getting mutex state/rt <-> non-rt communication

[Xenomai-help] Getting mutex state/rt <-> non-rt communication

[Maciek Godek]

Hi,
is it obligatory to use the rt_mutex_inquire in order to get the mutex
state, or could I possibly use the field lockcnt from struct RT_MUTEX
directly? (the test should be, as I believe, atomic - so should I
worry?)

The thing is that I'm using mutices for IPC between an rt-task and a
regular linux process. The rt code is critical, but in the
non-realtime code I can pay the cost of low latency polling to find
out if the realtime code has finished. (Perhaps there is a better way
to do it? The code now looks like this:

RT_MUTEX busy;
RT_COND data_ready;
// both are initialized (elsewhere)

void realtime_thread(void *) {
  rt_mutex_acquire(&busy, 0);
  for(;;) {
    rt_cond_wait(&data_ready, &busy, TM_INFINITE);
    // here it does something critical - it actually communicates
    // with an external device over serial port using the famous rtdm
    // serial driver developed and maintained by Jan Kiszka.
  }
}
 ...
// there is only one thread that communicates with the realtime
// thread above - and this code is invoked within it.
rt_cond_signal(&data_ready);
// now the rt-thread does something. I can estimate the upper time limit
// of the one iteration of that task.
usleep(predicted_time);
if(busy.lockcnt) {
  // timeout - this is possible as it depends on the external devices. Of course
  // sooner or later the mutex will be released by the rt thread.
}

is there any wiser way to communicate these threads?)

Re: [Xenomai-help] Getting mutex state/rt <-> non-rt communication

[Jan Kiszka]

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

Maciek Godek wrote:
> Hi,
> is it obligatory to use the rt_mutex_inquire in order to get the mutex
> state, or could I possibly use the field lockcnt from struct RT_MUTEX
> directly? (the test should be, as I believe, atomic - so should I
> worry?)

UAAAH!!! Don't do this, never!

Locking a mutex means more, e.g. assigning a _schedulable_ Xenomai
thread as owner so that one can raise its priority if a higher thread
contents for the same lock. It also means blocking if the mutex is
currently locked, also requiring Xenomai thread context.

> 
> The thing is that I'm using mutices for IPC between an rt-task and a
> regular linux process. The rt code is critical, but in the
> non-realtime code I can pay the cost of low latency polling to find
> out if the realtime code has finished. (Perhaps there is a better way
> to do it? The code now looks like this:
> 
> RT_MUTEX busy;
> RT_COND data_ready;
> // both are initialized (elsewhere)
> 
> void realtime_thread(void *) {
>   rt_mutex_acquire(&busy, 0);
>   for(;;) {
>     rt_cond_wait(&data_ready, &busy, TM_INFINITE);
>     // here it does something critical - it actually communicates
>     // with an external device over serial port using the famous rtdm
>     // serial driver developed and maintained by Jan Kiszka.
>   }
> }
>  ...
> // there is only one thread that communicates with the realtime
> // thread above - and this code is invoked within it.
> rt_cond_signal(&data_ready);
> // now the rt-thread does something. I can estimate the upper time limit
> // of the one iteration of that task.
> usleep(predicted_time);
> if(busy.lockcnt) {
>   // timeout - this is possible as it depends on the external devices. Of course
>   // sooner or later the mutex will be released by the rt thread.
> }
> 
> is there any wiser way to communicate these threads?)

Kernel or user space?

Jan


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

Re: [Xenomai-help] Getting mutex state/rt <-> non-rt communication

[Jan Kiszka]

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

Maciek Godek wrote:
> 2007/5/16, Jan Kiszka <jan.kiszka@domain.hid>:
>> Maciek Godek wrote:
>> > Hi,
>> > is it obligatory to use the rt_mutex_inquire in order to get the mutex
>> > state, or could I possibly use the field lockcnt from struct RT_MUTEX
>> > directly? (the test should be, as I believe, atomic - so should I
>> > worry?)
>>
>> UAAAH!!! Don't do this, never!
> 
> Oh, calm down, I was just joking :D

You wouldn't bet how much code if this kind is out there - in "real" use...

> 
>> Locking a mutex means more, e.g. assigning a _schedulable_ Xenomai
>> thread as owner so that one can raise its priority if a higher thread
>> contents for the same lock. It also means blocking if the mutex is
>> currently locked, also requiring Xenomai thread context.
> 
> OK. But! here I think the situation is straightforward - there is only
> one xenomai thread and one non-rt thread. There is only one claimant
> to the mutex and I can tell for sure that there won't be any more.

"Nothing can happen, I'm running this on UP, there will _never_ be any
second CPU." Kind of famous last words. It's simply weak design, and you
can count on someone not reading the instruction manual that defines
this restricted environment.

> 
>> > The thing is that I'm using mutices for IPC between an rt-task and a
>> > regular linux process. The rt code is critical, but in the
>> > non-realtime code I can pay the cost of low latency polling to find
>> > out if the realtime code has finished. (Perhaps there is a better way
>> > to do it? The code now looks like this:
>> >
>> > RT_MUTEX busy;
>> > RT_COND data_ready;
>> > // both are initialized (elsewhere)
>> >
>> > void realtime_thread(void *) {
>> >   rt_mutex_acquire(&busy, 0);
>> >   for(;;) {
>> >     rt_cond_wait(&data_ready, &busy, TM_INFINITE);
>> >     // here it does something critical - it actually communicates
>> >     // with an external device over serial port using the famous rtdm
>> >     // serial driver developed and maintained by Jan Kiszka.
>> >   }
>> > }
>> >  ...
>> > // there is only one thread that communicates with the realtime
>> > // thread above - and this code is invoked within it.
>> > rt_cond_signal(&data_ready);
>> > // now the rt-thread does something. I can estimate the upper time
>> limit
>> > // of the one iteration of that task.
>> > usleep(predicted_time);
>> > if(busy.lockcnt) {
>> >   // timeout - this is possible as it depends on the external
>> devices. Of course
>> >   // sooner or later the mutex will be released by the rt thread.
>> > }
>> >
>> > is there any wiser way to communicate these threads?)
>>
>> Kernel or user space?
> 
> User space (I wouldn't dare to call usleep from kernel)
> (the solution for the kernel space would also be quite interresting,
> though)

In user space, you can simply map the non-rt mutex locker on a Xenomai
thread of priority 0. That means it will be scheduled with SCHED_OTHER
in Linux mode and at lowest RT prio when holding the mutex (unless it
undergoes prio inheritance). Kernel space would have been tricky as
there are no shadow threads to move between both worlds.

Jan


PS: Reply-to-all...


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

Re: [Xenomai-help] Getting mutex state/rt <-> non-rt communication

[Maciek Godek]

> >> Locking a mutex means more, e.g. assigning a _schedulable_ Xenomai
> >> thread as owner so that one can raise its priority if a higher thread
> >> contents for the same lock. It also means blocking if the mutex is
> >> currently locked, also requiring Xenomai thread context.
> >
> > OK. But! here I think the situation is straightforward - there is only
> > one xenomai thread and one non-rt thread. There is only one claimant
> > to the mutex and I can tell for sure that there won't be any more.
>
> "Nothing can happen, I'm running this on UP, there will _never_ be any
> second CPU." Kind of famous last words. It's simply weak design, and you
> can count on someone not reading the instruction manual that defines
> this restricted environment.

Yeah, I bet you're right. It requires lots of knowledge to do it well, though.
BTW do you know any good books on that topic? (design of real-time
multi-task systems)

> >> > The thing is that I'm using mutices for IPC between an rt-task and a
> >> > regular linux process. The rt code is critical, but in the
> >> > non-realtime code I can pay the cost of low latency polling to find
> >> > out if the realtime code has finished. (Perhaps there is a better way
> >> > to do it? The code now looks like this:
> >> >
> >> > RT_MUTEX busy;
> >> > RT_COND data_ready;
> >> > // both are initialized (elsewhere)
> >> >
> >> > void realtime_thread(void *) {
> >> >   rt_mutex_acquire(&busy, 0);
> >> >   for(;;) {
> >> >     rt_cond_wait(&data_ready, &busy, TM_INFINITE);
> >> >     // here it does something critical - it actually communicates
> >> >     // with an external device over serial port using the famous rtdm
> >> >     // serial driver developed and maintained by Jan Kiszka.
> >> >   }
> >> > }
> >> >  ...
> >> > // there is only one thread that communicates with the realtime
> >> > // thread above - and this code is invoked within it.
> >> > rt_cond_signal(&data_ready);
> >> > // now the rt-thread does something. I can estimate the upper time
> >> limit
> >> > // of the one iteration of that task.
> >> > usleep(predicted_time);
> >> > if(busy.lockcnt) {
> >> >   // timeout - this is possible as it depends on the external
> >> devices. Of course
> >> >   // sooner or later the mutex will be released by the rt thread.
> >> > }
> >> >
> >> > is there any wiser way to communicate these threads?)
> >>
> >> Kernel or user space?
> >
> > User space (I wouldn't dare to call usleep from kernel)
> > (the solution for the kernel space would also be quite interresting,
> > though)
>
> In user space, you can simply map the non-rt mutex locker on a Xenomai
> thread of priority 0. That means it will be scheduled with SCHED_OTHER
> in Linux mode and at lowest RT prio when holding the mutex (unless it
> undergoes prio inheritance). Kernel space would have been tricky as
> there are no shadow threads to move between both worlds.

I read these words, but I don't get their meanings. How should this be done?

>
> PS: Reply-to-all...

OK, sorry - I've accustomed to the sort of mailing lists where there
everything is posted to one address only. My fault.

Maciek

Re: [Xenomai-help] Getting mutex state/rt <-> non-rt communication

[Jan Kiszka]

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

Maciek Godek wrote:
>> >> Locking a mutex means more, e.g. assigning a _schedulable_ Xenomai
>> >> thread as owner so that one can raise its priority if a higher thread
>> >> contents for the same lock. It also means blocking if the mutex is
>> >> currently locked, also requiring Xenomai thread context.
>> >
>> > OK. But! here I think the situation is straightforward - there is only
>> > one xenomai thread and one non-rt thread. There is only one claimant
>> > to the mutex and I can tell for sure that there won't be any more.
>>
>> "Nothing can happen, I'm running this on UP, there will _never_ be any
>> second CPU." Kind of famous last words. It's simply weak design, and you
>> can count on someone not reading the instruction manual that defines
>> this restricted environment.
> 
> Yeah, I bet you're right. It requires lots of knowledge to do it well,
> though.
> BTW do you know any good books on that topic? (design of real-time
> multi-task systems)

/me could only provide academic references (thick books, you know...).

> 
>> >> > The thing is that I'm using mutices for IPC between an rt-task and a
>> >> > regular linux process. The rt code is critical, but in the
>> >> > non-realtime code I can pay the cost of low latency polling to find
>> >> > out if the realtime code has finished. (Perhaps there is a better
>> way
>> >> > to do it? The code now looks like this:
>> >> >
>> >> > RT_MUTEX busy;
>> >> > RT_COND data_ready;
>> >> > // both are initialized (elsewhere)
>> >> >
>> >> > void realtime_thread(void *) {
>> >> >   rt_mutex_acquire(&busy, 0);
>> >> >   for(;;) {
>> >> >     rt_cond_wait(&data_ready, &busy, TM_INFINITE);
>> >> >     // here it does something critical - it actually communicates
>> >> >     // with an external device over serial port using the famous
>> rtdm
>> >> >     // serial driver developed and maintained by Jan Kiszka.
>> >> >   }
>> >> > }
>> >> >  ...
>> >> > // there is only one thread that communicates with the realtime
>> >> > // thread above - and this code is invoked within it.
>> >> > rt_cond_signal(&data_ready);
>> >> > // now the rt-thread does something. I can estimate the upper time
>> >> limit
>> >> > // of the one iteration of that task.
>> >> > usleep(predicted_time);
>> >> > if(busy.lockcnt) {
>> >> >   // timeout - this is possible as it depends on the external
>> >> devices. Of course
>> >> >   // sooner or later the mutex will be released by the rt thread.
>> >> > }
>> >> >
>> >> > is there any wiser way to communicate these threads?)
>> >>
>> >> Kernel or user space?
>> >
>> > User space (I wouldn't dare to call usleep from kernel)
>> > (the solution for the kernel space would also be quite interresting,
>> > though)
>>
>> In user space, you can simply map the non-rt mutex locker on a Xenomai
>> thread of priority 0. That means it will be scheduled with SCHED_OTHER
>> in Linux mode and at lowest RT prio when holding the mutex (unless it
>> undergoes prio inheritance). Kernel space would have been tricky as
>> there are no shadow threads to move between both worlds.
> 
> I read these words, but I don't get their meanings. How should this be
> done?

rt_task_shadow(&task, name, priority, flags);
(with priority == 0)

From that point on, you can safely use rt_mutex_lock and your task
quickly goes non-rt again when releasing the lock (or doing something
dumb inside the lock...).

> 
>>
>> PS: Reply-to-all...
> 
> OK, sorry - I've accustomed to the sort of mailing lists where there
> everything is posted to one address only. My fault.
> 
> Maciek

Jan


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