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 Adding it to the inner functions turned out to be cleaner. I also queued a patch to change the reason code when reporting a rescnt imbalance in the future. Please review/merge. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-DE Corporate Competence Center Embedded Linux _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
