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?)
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
