Hi, The ec_ioctl_lock_up() and ec_ioctl_lock_down_interruptible() calls were added to protect the following functions when multiple send/receive loops are running: - ec_master_send() - ec_master_receive() - ec_master_domain_process() - ec_master_domain_queue()
In my opinion any locking on these functions should be at the application level instead. However, if they are being called from multiple processes (rather than threads) then you need to use something like a named semaphore so that all processes share the same lock. Of course if you are using callbacks (for EoE) you are probably doing that anyway. The reason that they have been named differently is that they are the functions that are called from the realtime send/receive loop and the define allows them to be ignored. RTAI (and Xenomi?) are NOT allowed to call standard Linux blocking functions from a hard realtime thread (to maintain hard realtime). The EC_IOCTL_RTDM define turns off these locks for (RTAI / Xenomi) RTDM applications to avoid this problem. They should probably also be turned off for RTAI / Xenomi in general and as I said above use application level locking. You can pass --enable-rtdm when compiling to enable RTDM (and compile rtdm-ioctl.o). So in summary: ec_ioctl_lock_up() and ec_ioctl_lock_down_interruptible() are for the hard realtime loop function calls, otherwise use the standard lock calls. Regards, Graeme Foot -----Original Message----- From: etherlab-dev [mailto:etherlab-dev-boun...@etherlab.org] On Behalf Of Esben Haabendal Sent: Wednesday, 28 February 2018 4:39 AM To: etherlab-dev@etherlab.org Subject: [etherlab-dev] ec_lock_* vs. ec_ioctl_lock in master/ioctl.c Hi I have been fixing a number of locking related issues, and have a hard time figuring out how to handle locking in general, and in master/ioctl.c in particular. As of patch base/0017-Master-locks-to-avoid-corrupted-datagram-queue.patch there is now the macro pair of ec_ioctl_lock_down_interruptible() and ec_ioctl_lock_up(), which maps to ec_lock_down_interruptible() and ec_lock_up() for the non RTDM use-case. But looking at the master/ioctl.c file as of patchset version 20171108, there are the following number of calls: 8 ec_lock_down() 52 ec_lock_down_interruptible() 129 ec_lock_up() 6 ec_ioctl_lock_up() 4 ec_ioctl_lock_down_interruptible() When should the ec_lock_* functions be called directly, and when should they be wrapped (and thus compiled out for RTDM)? And how is this supposed to work for RTDM in the first place? I mean, there are code outside of ioctl.c which is called from ioctl.c which are taking locks. Isn't this kind of defeating the purpose of this idea? Also, as far as I can see, EC_IOCTL_RTDM is only defined when compiling rtdm-ioctl.c. When and how is master/ioctl.c supposed to be compiled with EC_IOCTL_RTDM defined? Best regards, Esben Haabendal _______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev _______________________________________________ etherlab-dev mailing list etherlab-dev@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-dev
