Re: flock LOCK_EX not locking exclusively

Here's what's happening: after one process unlinks the file, other processes are still able to flock their open file handles after the first process closes its file handle:

          child 1      child 2
          open(...)
                       open(...)
          flock(...)
          unlink(...)
          close(...)
                       flock(...) (succeeds!)
          ...          ...
[download]

In general flock and unlink on the same file do not work well together. You really only want to use flock on a file which will always exist. Assuming that in this case you are simulating a pool of worker threads trying to grab a unit of work, you can fix things by checking to see if the file still exists after the flock succeeds.

Comment on Re: flock LOCK_EX not locking exclusively Select or Download Code

Replies are listed 'Best First'.
Re^2: flock LOCK_EX not locking exclusively by Anonymous Monk on Jan 03, 2008 at 09:30 UTC
Checking if the file exists after the flock is not good enough. Assume the check is done with a stat. child 1 child 2 child 3 open open flock (works for obvious reasons) stat (works for obvious reasons) unlink close open (creates a new file) flock (works, no contention on new file) stat (works, new file exists) flock (works, no contention on old file) stat (works, new file exists)	[reply]
Re^3: flock LOCK_EX not locking exclusively by pc88mxer (Vicar) on Jan 03, 2008 at 15:51 UTC
Well, if your `open` can create files, then obviously you'll have a problem. I was assuming that `open` would be used with mode `<`. In general, if file names can never reappear after being deleted you can use this method. That's why I say that `flock` generally doesn't work well with `unlink`.	[reply] [d/l] [select]