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

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- 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 --]