Closed kuggenhoffen closed 8 years ago
@kjbracey-arm @TeroJaasko @SeppoTakalo @tommikas I think the previous fix still had possibility of modifying mutex_lock_count during the last loop iteration immediately after releasing the mutex resulting in unexpected behavior.
Don't merge yet, I will test this still tomorrow morning.
Guys does this look good now? The unittest coverage fails because this removes 1 line completely and resulting coverage is 0.04% less than previously....
@SeppoTakalo @TeroJaasko I explained the mutex unlock loop a bit more on the comment here, let me know if it still is not obvious enough.
@kuggenhoffen It's green now.
@SeppoTakalo : A comment in the original PR: https://github.com/ARMmbed/mbed-trace/pull/30#issuecomment-223763607
That comment seems fairly explicit.
@SeppoTakalo Please make a PR to mbed-os for this fix as well. We need to get this in mbed-os 5.2
Fix in #51 still had possibility of unexpected behavior as the mutex_lock_count variable might get modified after releasing mutex during last loop iteration.