Exclusive flock will wait for previous exclusives to release before it will do its thing, i.e. it blocks. We flock on every file read & write, so yes, we are checking.

I've personally rewritten each of what used to be seperate file I/O routines to use what is now only a handful - all of which use the same model:

Verbatim from one of the routines:

    open(FILE, ">$path") or die "$! writing $path";
    &lock;    # calls flock(FLOCK_EX) and logs
    print FILE $string;
    &unlock;    # calls flock(FLOCK_UN) and logs
    close FILE;
[download]

(Yes, we are using strict... *FILE has been localized. The perils of inheriting someone else's work... :( :( :( )

Further thoughts? Thanks!

One of the common problems people have with file locking is failing to append correctly. Your verbatim example didn't suggest that you were appending, but if other snippets of your code read

  open(FILE, ">>$path") or die "$! writing $path";
  &lock;  # calls flock(FLOCK_EX) and logs
  print FILE $string;
  &unlock; # calls flock(FLOCK_UN) and logs
  close FILE;
[download]

then you have a race condition that can cause file corruption.

Consider what happens if the open succeeds and the flock blocks to obtain the lock. The open has positioned you for writing to the end of the file. But if the process that holds the lock writes after you've opened the file, the end-of-file mark moves. You're now positioned to overwrite whatever the other process wrote. If your string is longer, their string gets lost. If your string is shorter, you probably corrupt the file.

The way around this is to seek to end-of-file after you've obtained the lock.

  open(FILE, ">>$path") or die "$! writing $path";
  &lock;
  seek(FILE, 0, 2);  # ensure positioned at EOF
  print FILE $string;
  ...
[download]


Update: This also applies when truncating a file. Only truncate after you've obtained an exclusive lock. If you truncate before locking, you risk pulling the rug out from under whatever process does have the lock.