Wolfgang Grandegger wrote: > Gilles Chanteperdrix wrote: >> Wolfgang Grandegger wrote: >>> Gilles Chanteperdrix wrote: >>>> Wolfgang Grandegger wrote: >>>>> Hi Gilles, >>>>> >>>>> Gilles Chanteperdrix wrote: >>>>>> Gilles Chanteperdrix wrote: >>>>>>>>> Now, the question is, do you realistically plan to write an >>>>>>>>> application >>>>>>>>> which makes no syscall in its real-time loop? >>>>>>>> Unlikely, but it may happen in case of programming errors. Anyhow, the >>>>>>>> pthreads will run legacy code and it would be a pain to add >>>>>>>> pthread_testcancel where necessary. But maybe there is a more elegant >>>>>>>> and simple solution to do a defined exit/abort. >>>>>>> In case of programming error, enable the xenomai watchdog, it will >>>>>>> forcibly kill the problematic thread. >>>>>> To give you a more complete answer: most blocking functions are >>>>>> cancellation points in the PTHREAD_CANCEL_DEFERRED case, so, you >>>>>> probably do not need to add pthread_testcancel at all. The only >>>>>> exception is pthread_mutex_lock: this way, cancellation happens for well >>>>>> defined mutex states, and you may install cleanup handlers with >>>>>> pthread_cleanup_push/pthread_cleanup_pop if ever a thread may be >>>>>> destroyed while holding a mutex. With PTHREAD_CANCEL_ASYNCHRONOUS, the >>>>>> situation is not that clean. >>>>> Well, there seems something wrong with it, also PTHREAD_CANCEL_DEFERRED >>>>> with pthread_testcancel does not work reliably and consistently and it >>>>> still behaves different on my ARM and PowerPC systems. I have attached >>>>> my revised test program allowing to enable/disable various method of >>>>> thread creation, setup and cancellation. They all work fine with the >>>>> Linux POSIX libraries. With Xenomai, only a few work as expected on my >>>>> ARM and PowerPC test systems. >>>> Could you explain us exactly what happens >>> OK, with the definitions >>> >>> //#define USE_SIGXCPU >>> //#define USE_EXPLICIT_SCHED >>> #define CANCEL_TYPE PTHREAD_CANCEL_DEFERRED >>> //#define CANCEL_TYPE PTHREAD_CANCEL_ASYNCHRONOUS >>> #define USE_TEST_CANCEL >>> >>> I get on my ARM MX31ADS system: >>> >>> -bash-3.2# ./cancel-test >>> Real-Time debugging started >>> Segmentation fault >>> >>> The program behaves differently when running under gdb but the >>> segmentation fault happens somewhere in pthread_cancel. It works better >>> on my PowerPC TQM5200 system: >>> >>> -bash-3.2# ./cancel-test >>> Real-Time debugging started >>> ctrl_func: started at count 0 >>> ctrl_func: sleeping for 2sec 500000000ns >>> calc_func: counting till 50 >>> calc_func: at count 0 >>> calc_func: at count 1 >>> calc_func: at count 2 >>> calc_func: at count 3 >>> calc_func: at count 4 >>> calc_func: at count 5 >>> calc_func: at count 6 >>> calc_func: at count 7 >>> calc_func: at count 8 >>> calc_func: at count 9 >>> calc_func: at count 10 >>> calc_func: at count 11 >>> calc_func: at count 12 >>> calc_func: at count 13 >>> calc_func: at count 14 >>> calc_func: at count 15 >>> calc_func: at count 16 >>> calc_func: at count 17 >>> calc_func: at count 18 >>> calc_func: at count 19 >>> calc_func: at count 20 >>> calc_func: at count 21 >>> calc_func: at count 22 >>> ctrl_func: cancel at count 23 >>> ctrl_func: stopped at count 23 >>> main terminating in 2 seconds... >>> >>> But the messages from calc_func are display before the task gets >>> actually canceled, which I do not understand. On ARM, it behaves similar >>> if I disable explicit setting of the cancellation type: >>> >>> //#define USE_SIGXCPU >>> >>> //#define USE_EXPLICIT_SCHED >>> >>> //#define CANCEL_TYPE PTHREAD_CANCEL_DEFERRED >>> >>> //#define CANCEL_TYPE PTHREAD_CANCEL_ASYNCHRONOUS >>> >>> #define USE_TEST_CANCEL >>> >>> >>> Enabling/disabling other options does not work as expected either, like >>> using USE_EXPLICIT_SCHED. The cancellation does then not work any more. >> The problem is that the way you create threads is racy, you do not know >> in which order the two tasks are created, and if ever calc_func is >> created before ctrl_func, it will use all the cpu and ctrl_func will not >> have a chance to interrupc calc_func. > > I already put some sleep or ctrl-thread-is-up test before creating > calc_thread, which did not help. Also the output above indicates that > ctrl_thread did start before calc_thread.
Unless I am wrong the output above indicates that the test works... What I am talking about is the cases where the test does not work, especially when USE_EXPLICIT_SCHED is not set. -- Gilles. _______________________________________________ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help