I can only imagine that __HAL_LOCK(x) is designed to make access to the HAL drivers thread safe. However, since the lock itself is not thread safe, the driver it's trying to protect is not thread safe either.
I've spent a day trying to work out how the UART transmitter was occasionally being disabled mid steam. It turned out to be a race condition with the UART receiver which should have been prevented by the __HAL_LOCK(x) macro.
The problem with __HAL_LOCK(x) has been known for several years and ST has promised a fix, but I haven't seen anything yet. I've only had experience with a couple of other HALs, but they were both thread safe.
I'm no expert, but to make it atomic, don't you just make the flag volatile and disable interrupts while it is being locked? You'd also need a memory barrier before re-enabling the interrupts.
Any, I just want to add my +1 to getting it fixed.
Cheers
David
