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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
