Mutex Usage - Best Way to do this?

I have automated some actions in my app that run on timers set by the user. The user can schedule something to happen at a particular day and time, repeated days, etc. I set a timer to execute the action at the desired time. Let’s call this an automation.

Now the user may be running both my desktop app for local access and my web app for remote access. On the backend, both apps do effectively the same thing - both read the same timer settings to automate the action desired. So both timers will fire and run about the same time. But I don’t want to run the automation twice.

So what I have been doing is the app that first starts to fire its timer sets a mutex. That way the second app tries to access the mutex, it fails and it doesn’t run the automation. Once the first app is done, it releases the mutex after a few seconds or is supposed to. I have seen an instance at a customer where it appears the mutex is somehow not releasing and this user doesn’t run the web app so it should just be the one app creating and releasing the mutex.

So this brings up some questions:

1.) Is this the proper use of a mutex
2.) Is a Mutex the best way to handle this sort of situation
3.) What happens if a Mutex goes out of scope? Does it release? In my case, I have the Mutex as a property of the timer that is executing the automation. That timer in some instances goes out of scope. So does the Mutex then get released?
4.) Any ideas on what could cause the situation where the app creates the mutex but it can’t access it?

Thanks!

I can’t answer your questions directly. But I use two ways for avoiding multiple use of a program or database:

  1. Mutex
    This works into a certain operating system.

  2. build an enqueue entry in a SQLite database
    This works into the network.

to 1)
I have an App with implemented mutex. It prevents the multiple use of my app since round about 2 years steadily.
The mutex becomes created into the open event of my app and becomes closed into the close event of my app.
I’ve never had a mutex which is going out of scope.

to 2)
I have a database table like this:

create table Sperrobjekte(Objekt string, Ausprgung string, Maschine string, Benutzer string, Zeitpunkt string, Sperre string, PID integer, primary key (Objekt, Ausprgung))
  • field Objekt can be a certain table or app (anything that should be enqueued)
  • field Ausprgung is the certain name of the object (i.e. a customer number)
  • field Maschine contains the computer name which is running the app
  • field Benutzer contains the user name
  • field Zeitpunkt contains a time stamp
  • field Sperre contains the ID for write lock or read lock
  • field PID contains the current process ID of the application

If the user starts to process an object, the app looks into the table for this object whether it can be read or changed. If there is a lock, the user gets message with the other user who is working with the needed object.
At the close event of the window the last written entry becomes removed.

With this construct you can avoid the multiple change or read of an object (with or without message).