New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove Mutex::_count #12976
Comments
@AriParkkila thank you for raising this issue.Please take a look at the following comments: We cannot automatically identify a release based on the version of Mbed OS that you have provided. NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'.This indicates to us that at least all the fields have been considered. |
@kjbracey-arm @ashok-rao Was this discussed this week in #12965 and #12964 ? |
@0xc0170 .. Nop. Looks like @AriParkkila came across "_count" and Mutex the same time we did, but our requirements are different.. |
Nice test. Weird lower loop, but maybe it's necessary to provoke failure. Hope you're not using it like that in practice. It should look more like
to make sure the Looks like I broke it in b8e80dd (#10358) Previous behaviour was always to decrement count inside the lock, before the unlock call. That was safe, but would have left it wrong in the event of any error, which is probably what I meant to fix, but that's not a big deal. Errors mean system death anyway. The original reason for it was purely to implement the I argued against the
No can do, as we always set that flag. There's currently no option to make a non-recursive But yes, that is the approach of C++11. You have to use |
Thanks, fixed in #12983. |
Description of defect
Mutex::_count should be removed or implemented properly.
Mutex
class is not actually using_count
for anything, but because it's updated without holding a lock that breaks implementation of the friend class ConditionVariable.I guess the original idea behind
_count
was to implement recursive mutex, but it's not really needed as that's already handled (properly) inrtx_mutex.c
. Also ifConditionVariable
need to guaranteeMutex
is non-recursive then simply deassert forosMutexRecursive
attribute.Target(s) affected by this defect ?
All with
rtos.present
.Toolchain(s) (name and version) displaying this defect ?
All.
What version of Mbed-os are you using (tag or sha) ?
#0c4e50abb3fa1ec3d80f19c88ceefa106ff94e64
What version(s) of tools are you using. List all that apply (E.g. mbed-cli)
How is this defect reproduced ?
E.g. this code:
... eventually it crashes:
The text was updated successfully, but these errors were encountered: