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