On 01/09/2013 02:30 PM, Jan Kiszka wrote: > On 2013-01-08 22:06, Jan Kiszka wrote: >> On 2013-01-08 20:43, Gilles Chanteperdrix wrote: >>> On 01/08/2013 12:12 PM, Mariusz Janiak wrote: >>> >>>> Hi GIlles, >>>> >>>> As you suggested, I have prepared simple test case that demonstrate how >>>> Xenomai is utilized by OROCOS. This test case behaves exactly the same >>>> like helloword example. Scheduler is chosen before any mutex are >>>> processed, so in my opinion it is not the case which you defined. What is >>>> really surprising is that the replacing TM_NONBLOCK with TM_INFINITE, in >>>> one before last line, do magic and suppress signal generation. >>>> Furthermore, there is no call to 'rt_task_set_mode(0, T_WARNSW, NULL);' so >>>> why >>>> signal is generated? If we enable T_WARNSW in the thread, SIGXCPU is >>>> generated when mutex is locked first time in the thread. >>> >>> >>> I guess the test could be simpler, simply: >>> >>> rt_mutex_acquire >>> rt_task_create >>> rt_mutex_release >>> rt_mutex_acquire >>> rt_mutex_release >>> >>> Anyway, calling rt_task_create while holding a real-time mutex is itself >>> a priority inversion: any thread in primary mode waiting for the mutex >>> will now have to wait for task running in secondary mode, so may be >>> block during an unbounded amount of time. So, using a real-time mutex >>> for this is completely useless you should be using a glibc >>> pthread_mutex_t. If compiling for the posix skin, use >>> __real_pthread_mutex_lock. >>> >>> Now, how this can cause the issue you observe remains to be understood, >>> and probably requires a fix. >> >> OK, second try: We do not update the new owner's hrescnt if we acquire a >> mutex via trylock. This applies both to rt_mutex_acquire_inner and >> pthread_mutex_trylock. Probably, this should be done in the >> corresponding syscall wrapper as both services are also used for the >> in-kernel API. > > Here is the corresponding patch:
> http://www.xenomai.org/pipermail/xenomai-git/2013-January/000336.html Ok, so, if I understand correctly, the whole orocos testcase boils down to: trylock unlock We should move the incrementation of the resource counter to xnsynch_fast_acquire. We will be left with only two places to patch: the native and posix trylock in the !FASTSYNCH case. -- Gilles. _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
