in reply to Update in-place with temporary file and flocking

Whenever I have a situation where multiple concurrent users or processes need brief exclusive access to some shared resource (usually to rewrite or append to a common data file), I tend to use a separate "semaphore" file -- in fact, I've needed this often enough that when I found a TPJ article by Sean Burke discussing semaphores in detail, I put his demo code into a module, which I now use regularly (there's a link to the article in the module docs).

The basic idea is that the semaphore file is always empty -- it exists purely to establish a lock on some particular resource. Get the lock on the semaphore file, and the resource is yours until you release the semaphore. This eliminates all the loop-holes, race conditions and weirdness of trying to grab and hold a lock on something that you're trying to change.

Of course, this only works in the cases where everyone agrees to cooperate (or the project is designed to enforce cooperation) and "update access" to the shared resource is always moderated via the specified semaphore -- it won't help in the case where some folks think they can ignore the semaphore stuff and just start hacking away at the actual data file (e.g. with vi or whatever).

  • Comment on Re: Update in-place with temporary file and flocking

Replies are listed 'Best First'.
Re: Re: Update in-place with temporary file and flocking
by geohar (Acolyte) on Feb 19, 2004 at 09:27 UTC
    Agreed. That'll probably be the solution I have to use. I was hoping however, to be able to get away with locking only the file I intended to update as this seemed neater. Clearly it's not as portable as I'd have thought though. A separate semaphore file would avoid rename failing because the destination file is locked on windows. (Neither the temporary, nor the real file would be locked at all). Just seems a shame that the above code isn't going to work reliably.