CRC Thread safety

[daniel-cesarini-tridonic-com]

Description

• Type: Enhancement | Question
• Priority: Major

Enhancement/Question

Reason to enhance or problem with existing solution
In the current implementation of CRC in mbed-os thread safety is not guaranteed:
#5911 (comment)

How to?
How do you envision to solve the issue?

Suggested enhancement
We implemented some time ago a CRC Class (https://github.com/ARMmbed/mbed-os/pull/3443/files) that deals with Thread safety by storing intermediate results in a local variables, such that no "lower level" context is needed, and only the time of accessing the lower layers should be mutexed / protected.
Is that approach fitting your needs?

@deepikabhavnani @sg- @MarceloSalazar

FYI: @markus-becker-tridonic-com

[deepikabhavnani]

@daniel-cesarini-tridonic-com Thanks for the proposed solution. We will definitely look into it during HW CRC implementation. Thread safety will be for sure required to support hardware CRC, and we have not finalized the HAL API's for that.

Also I suppose we will have mutex locking for low level access just like other drivers. https://github.com/ARMmbed/mbed-os/blob/master/drivers/AnalogIn.cpp#L23

@bulislaw

[daniel-cesarini-tridonic-com]

The solution is actually not handling the mutual access, it is only providing a "multiplexed" access to the CRC lower level in case of usage of "CRC accumulation" functionality by storing the intermediate results in a local variable in order to free the resource of CRC lower level in the meanwhile.

[deepikabhavnani]

Storing intermediate results in the class will be bit tricky for different devices, some of them maintain the states and store the intermediate values themselves and some do not support partial CRC. Our API's are designed to return the intermediate values, and the application/thread using it has to make sure it passes the correct intermediate value back for rest of the calculation.

Sorry I didn't get the chance to study your solution fully, we will have a look during HW CRC implementation which is not planned in near future.

[bulislaw]

@scartmell-arm fyi

[ciarmcom]

ARM Internal Ref: MBOTRIAGE-98

[daniel-cesarini-tridonic-com]

Would this MR (already merged) #7781 close this issue?

[deepikabhavnani]

Yes. Thanks