Maciek Godek wrote: > 2007/5/16, Jan Kiszka <[EMAIL PROTECTED]>: >> 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...
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
