Don’t have much to say other than what was said in the title. I can see that vex::mutex does have a destructor based on vex_thread.h, but I don’t have a V5 brain available to test on at the moment to actually confirm this.
No, and you really don’t want it to go out of scope.
There’s very few situations where a mutex would be needed, what’s the application ?
5 Likes
In my case, i’m trying to ensure that data stays up-to-date when getting/setting things from a custom Drivetrain class that happens to run its own thread for motion control/position tracking. The thread continiously updates a few things in the background at a set sample rate (every 10ms), and I want to make sure that communication between the main thread and drivetrain thread doesn’t end up resulting in a some race condition where a condition isn’t set before a target is updated.
I’m not sure if it is possible in vexcode like it is in PROS, but it you might be able to use std::scoped_lock or another class defined in the header to manage your mutex with RAII semantics.
The version of the standard library that vexcode ships with is somewhat stripped down, so I don’t believe scoped_lock isn’t available. Anyways, things seem to be working fine with vex::mutex, it’s just a little more verbose.