Steve Deiters wrote: >> The set of services which you can call from a real-time >> thread without loosing determinism are those found in the >> Xenomai posix skin documentation: >> http://www.xenomai.org/documentation/xenomai-2.5/html/api/grou >> p__posix.html >> >> Other than that, any service emitting a syscall causes a >> switch to secondary mode. What remains are services not >> emitting syscalls, and for these ones, all bets are off. >> >> -- >> Gilles. >> > > I guess that is my point though. Not being all too familiar with the > inner workings of Linux or glibc, how am I supposed to know which > services are not emitting a syscall? I accept that I will lose > determinism in calling these services, but I find it odd that it may > allow the system to deadlock. > > If nothing else the syscall-less services should be listed and noted as > unsafe. I am new to most of this, but I have went through most of the > documentation and, unless I have overlooked it, found nothing mentioning > this.
Key services that do not reliably trigger syscalls: - gettimeofday - clock_gettime (unless the POSIX skin is in use) - malloc - free There are no guarantees either, but this list turned out to be fairly complete while porting a large (x86) application from plain Linux to Xenomai. Only gettimeofday (and, conditionally, clock_gettime) suffer from the live-lock problem. For runtime checks, enable T_WARNSW / PTHREAD_WARNSW for your RT threads, additionally link against librtdk, --wrap the above services, and assert_nrt() will trigger a SIGDEBUG when they are used from a RT thread (just like normal syscalls will do). There should be a few more services in the glibc that trigger malloc internally without issuing a syscall. When you come across one (check the man pages), additions to xenomai/src/rtdk/assert_context.c are welcome. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
