Is implementing a mutex in shared memory the best idea 359

You latched on to my mention of semaphores a bit too soon ;-) I did not realize at the time that your "shared memory" consisted of a common nfs mounted filesystem.

If you have a shared file and you want to ensure that only one process at a time is writing to it, then you should use rpc.lockd . You could just request locking the entire file, or if you can divide your work more finely, you could lock particular records.

If for some reason you cannot use rpc.lockd then you can fake a lock by using open() with OCREATOEXCL in the option and naming a file in a shared nfs directory. If another process already has the file open then the open() will fail, so your process could sleep and try again later. If the open() succeeds then you own the lock and can go ahead and write to the shared mmap()'d file.

The make-shift lock will persist as long as the file exists with that name. If the writing process is somehow able to detect that it is now safe for other processes to write to the shared area, then the writing process could be the one that removes the file. It might, though, turn out to make more sense to have the reading server process remove the lock file when it has finished processing the data. You will, though, need to find some way for the writing process to signal to the reading process that it has finished putting in the request.