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. Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20130108/45a67755/attachment.pgp> _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
