Jan Kiszka wrote:
Wolfgang Grandegger wrote:
Jan Kiszka wrote:
Jan Kiszka wrote:
I thought about this issue again and found the reason for my vague bad
feeling: re-init is not atomic, thus racy. But also the test+sem_init
pattern I suggested is not save.

I guess we need to enhance rtdm_XXX_init in this regard to make the
RT-CAN use case an officially allowed one. /me is planning to spend more
thoughts on this the next days.
OK, done, rtdm_{event,sem,mutex}_init are now protected by the nklock in
trunk. This should make the in-place re-initialisation of RTDM IPC
objects race-free and allow to use them in RT-CAN as originally
intended. I think I will back-port that pieces also to v2.3.x later.

Well, I looked to your changes and do not yet understand what they are good for. From my point of view, it does _only_ make sense to use "init" and "destroy" in a serialized way, like RT-Socket-CAN does. If you do "re-init" without destroy, you might be in trouble if the object is in a wait state. Have I missed something?

What patch should now go in to avoid double init/destroy and fix
Attached. Thanks.

Just applied to trunk.


To avoid lock nesting where possible, I reordered some code in
rtcan_raw_sendmsg. Please re-check if I messed anything up. Then I could
commit to stable, too.

Hm, I do not see critical changes in rtcan_raw.c. I have tested the CAN drivers today and did'nt realize any new problem, apart from an old bug :-(fix coming soon).



Xenomai-core mailing list

Reply via email to