Hi, Im new to programming and trying to get my head around the locking process with mesa variables. I have the problem below.

SensorMonitor M;
int main() {
...
M.LockSensorAccess();
/* Access the sensor, reconfigure the sensor, ... */
M.FreeSensorAccess();
...
}
Monitor SensorMonitor {
/* monitor variables here */
void LockSensorAccess() { /* Code here */ }
void FreeSensorAccess() { /* Code here */ }
}

An externalsensor is connected to a computer by a serialline.
Only one process at a time can communicate with the The sensor. controller of the serial line can maintain access to the sensor from
at most 7 processes. Im trying to write in pseudo-code monitor to coordinate process access to the
external sensor. The monitor pseudo-code needs to define monitor variables and
the monitor functions so that at most only 7 processes are actually
communicating with the sensor. Can anyone help me regarding this and help me understand it.

Regards

Jon

Jono_Buzz,

I may be able to help in a small way. I fairly sure Mesa variables are like any other variable, and synchronization of processes is very much like synchronization of threads in a multi-threaded program.

This link might help shed a light on synchronization: Semaphore Examples or Basic Multithread Programming and Synchronization (Futex, Semaphores, Mutex, etc)

What's your ideal of the interaction between active processes, what are your thoughts on how they should signal each other related to the shared serial line? Thinking this through for a moment, allowing processes to talk directly to the serial could be problematic, beyond trying to constrain the number of processes to seven. In short this approach burdens all involved processes with needing the knowledge of inter-process signaling and the operational details of the serial ;line, along with the required knowledge of how to operate the device to extract valid information. This is exactly why device drivers were created!

I would entertain one program (controller) owning the serial line resource and containing all the functionality required to extract information from the attached device. This controller would then establish a request/response messaging protocol that would allow any number of processes to make requests. Maybe using Message Queues as the IPC between processes.

Hope this helps establishes a design model for What can be done. How do you want to proceed; peer processes sharing a serial line; or the controller IPC model?

Jono_Buzz,

This kind of synchronization is all voluntary, you hope that all process play by the same rules. Assume the interprocess flag is a regular file named 'locked.ser'. If the file exists then the serial line has been locked by a process. If the file does not exist then the serial line is available to be locked. Also, we all agree that we will not access the serial line unless we created the lock, and we also agree to delete the lock as soon as we are done with the serial line.

Whether you use a file that all processes can see, semaphores, or something else. you must synchronized access to serial line, which can only have one user at a time.

I'm not going to try to second-guess the code that you have. But here are a few ideas (assuming POSIX threads).

(1) If you want to ensure that no more than 7 processes can do something, use a semaphore that is initialized to the value "7." Each process that wants to use the monitor (at all) must first sem_wait() on this semaphore, then must continue to hold the semaphore until it no longer needs to use the monitor. (It could hold this semaphore for quite some time.) Then, sem_post() to give-up its right to use the monitor. You aren't allowed to touch the monitor unless you hold this semaphore. The only purpose of this semaphore is to "wait in line."

(2) The monitor itself is secured by a second semaphore with a value of 1 (a "mutex"), so that only one process can hold it at any time. Exception-handling (try..finally) is used to ensure that this semaphore is always unlocked by any process that has locked it.

If the process of "waiting in line until it's my turn" is immediately followed by doing something with the monitor and then immediately relinquishing semaphore #1, then that's how you write it. First, the process waits in line. Then, it locks the mutex, does its business, releases it. Finally, it releases the wait-in-line semaphore. Exception handling is used to guarantee that this will always be done even if the process has encountered a runtime error along the way.