Many methods that ControlBoardDriver class implements have different overloads:
Act on a single joint
Act on all joints
Act on a subset of joints
While for the first case the methods have a lock_guard to guarantee a safe access to control board data, the other two typically have not that, because in principle they call the method version for the single joint for every robot joint. However In many of these methods there still some control board data members are accessed without a lock, potentially causing race conditions.
Many methods that
ControlBoardDriverclass implements have different overloads:While for the first case the methods have a lock_guard to guarantee a safe access to control board data, the other two typically have not that, because in principle they call the method version for the single joint for every robot joint. However In many of these methods there still some control board data members are accessed without a lock, potentially causing race conditions.
An example is: https://github.com/robotology/gz-sim-yarp-plugins/blob/13aa1987a54229aa953c2061d68a66c1d4cb7c26/plugins/controlboard/src/ControlBoardDriver.cpp#L86-L103
in which
m_controlBoardData->joints.size()is called.A way to avoid this is to switch to recursive mutex objects, so that the same mutex can be locked multiple times by nested functions.