The EasyGoPiGo3 and Easy<SensorX> classes pass down a “use_mutex = True” instantiation for “safe” access methods to some shared resources.
I have made it a practice to always write my GoPiGo3 Python programs using the EasyGoPiGo3 class with “use_mutex = True” even if the program functionality does not use multi-tasking or multi-processing. This way, if I launch two independent Python processes that may use a common sensor such as a Distance Sensor, individual accesses will be “safe”.
(This does not protect against one process setting a sensor to a different mode, but should maintain single access integrity for two processes reading the same sensor over a “single user bus” such as I2C. )
I should note that two processes instantiating separate EasyGoPiGo3 objects are sharing the GoPiGo3 robot, but the object methods are totally unaware of each others’ actions and instance variables, so unexpected behaviors may result without the objects complaining with a warning or error condition.
Q) I always declare with “use_mutex = True”. So I do have I2C mutex protection across tasks - Correct?
Q) Is the SPI bus mutex protected?
Q) Does the GoPiGo3 use any other mutex protection?
Q) The load_robot_constants() and save_robot_constants() are not mutex protected, correct?
Q) Is mutex.overall_mutex() DexterLockI2C?
This is the state of my /run/lock/ folder:
-rwxrwxrwx 1 root root 0 Jan 6 13:08 DexterLockI2C
-rwxrwxrwx 1 pi pi 0 Jan 5 10:16 DI_Mutex_egpg
-rwxrwxrwx 1 pi pi 0 Jan 4 14:06 DI_Mutex_I2C_Bus_GPG3_AD1
-rwxrwxrwx 1 root root 0 Jan 6 13:08 DI_Mutex_I2C_Bus_RPI_1
-rwxrwxrwx 1 pi pi 0 Jan 6 11:28 DI_Mutex_I2C_Bus_RPI_1SW
The timestamps are changing on:
-rwxrwxrwx 1 root root 0 Jan 6 13:27 DexterLockI2C
-rwxrwxrwx 1 root root 0 Jan 6 13:27 DI_Mutex_I2C_Bus_RPI_1
since Carl is running his “juicer” program which accesses the Distance Sensor via HW I2C.
The _AD1 is from when I am testing the IMU sensor.
(The DI_Mutex_egpg was from a test_gopigo3_vars.py and test_gopigo3_vars_2.py I wrote to prove class variables are not global across instances.)
That’s an interesting idea! Honestly, it’s not on by default (it’s not even documented!) for historical reasons.
I got fed up one day and implemented this to simplify my own life for a specific project. It’s probably time to bubble it up and make it known.
I want some time to think whether there are any drawbacks to making it the default.
@cyclicalobsessive brought up a good point that it contradicts the documented behavior of the easygopigo class.
Perhaps one (or both) of two thigs can happen:
Change the default behavior of the class to use mutexes by default.
Document this behavior somewhere within the main documentation for the easygopigo class.
I absolutely disagree with the idea that deliberately, (or even inadvertently), placed land-mines are a “part of the pedagogy”. The student, (or anyone else for that matter!), already has more than enough opportunities to make a bloody arse of themself without help.
I am a very strong advocate for the concept of “closure” as a design concept and/or design requirement.
“Closure” demands that a design - whatever it may be - either limit the user, or guide the user as an absolute minimum, to correct behavior or action.
Deliberately or even inadvertently placed land-mines are always wrong.
In this particular case, since the use of mutexes appears to be a desirable behavior, and solves/prevents many problems, it should be the default behavior that can be overloaded to disable, if needed.