Use_mutex, "safe", multi-task and multi-processing

GoPiGo
1

Continuing here - the mutex and the EasyXXX “safe” methods discussion that hijacked GoPiGo Line Follower Assembly Instructions out-of-date:

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.

1 Like
2

If you create this file /run/lock/DexterLockI2C then you will be able to have mutex across tasks too.

Just run the following in a terminal:
touch /run/lock/DexterLockI2C

1 Like
3

Ok, now I’m a little confused.

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
and
-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.)

1 Like
4

My apologies… I went too fast, and I was on a cell phone.

Here’s the filename : /run/lock/DexterOS_overall_mutex

Mea Culpa

Oh, and once that file is created, you no longer have to care about the use_mutex parameter. It will be considered True across the board. That’s quite handy, and saved me a few times :slight_smile:

2 Likes
5

Maybe it should exist by default?

Why not?

1 Like
6

Perhaps because it would be a very, very well hidden intrinsic behavior that would override the visible Class mutex init parameter?

Learning about the need for a mutex (when folks start multi-tasking and multi-processing and mysterious things happen) is part of the pedagogy.

1 Like
7

I still think desirable behaviors should be the default. Silly perhaps, but that’s me.

Why make someone run down the hall and climb two flights of stairs to find the fire extinguisher that should have been right next to him?

Or is going bonkers during an emergency part of the pedagogy? :stuck_out_tongue_winking_eye:

1 Like
8

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.

1 Like
9

@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:

  1. Change the default behavior of the class to use mutexes by default.
  2. 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.