SNIP_CLASSIC_CAN_SECTION_7_10_Reentrancy_issues

7.10 Reentrancy issues A routine must satisfy the following conditions to be reentrant: • It uses all shared variables in an atomic way, unless each is allocated to a specific instance of the function. • It does not call non-reentrant functions. • It does not use the hardware in a non-atomic way. Transmit requests are simply forwarded by the CanIf module inside the function CanIf_Transmit. The function CanIf_Transmit is re-entrant. Therefore the function Can_Write needs to be implemented thread-safe (for example by using mutexes): Further (preemptive) calls will return with CAN_BUSY when the write can’t be performed re-entrant. (example: write to different hardware TX Handles allowed, write to same TX Handles not allowed) In case of CAN_BUSY the CanIf module queues that request. (same behavior as if all hardware objects are busy). Can_EnableCanInterrupts and Can_DisableCanInterrupts may be called inside re-entrant functions. Therefore these functions also need to be reentrant. All other services don’t need to be implemented as reentrant functions. The CAN main functions (i.e. Can_MainFunction_Read) shall not be interrupted by themselves. Therefore these CAN main functions are not reentrant.