flock implements advisory locking, which means that other applications are free to ignore the lock. The Windows emulation of flock uses mandatory locking, which means that other applications cannot ignore the lock.

Here's one way of doing the same without the extra file:

use strict;
use Fcntl qw( LOCK_EX SEEK_SET );

my $file = 'data.file';

open(my $FH, '>>', $file)
   or die("Can't open $file: $!\n");
flock($FH, LOCK_EX);
seek($FH, SEEK_SET, 0);
truncate($FH, 0);
...
[download]

Hi,
Thanks for the code.
I had a question about that code.
I do not understand why you would want to truncate the file you are trying to append to ? I also do not understand why
you would use seek . I am really getting confused
I know its just an example. I am just wondering the reasoning behind it?

We want to clobber the file, but we don't want to clobber the file until we've locked it. The catch is that one can't lock a file one doesn't have open, so we can't use open ">" to clobber the file. That means we have to start by opening the file without clobbering it (e.g. by using open ">>") and by locking it. Then, we're free to clobber it.

i stay away from file locking as much as possible. for the most part it is advisory locking, so you need to write programs that use flock and read/write clode blocks in an atomic way that prevents race conditions or lockup. there's specific ways you are meant to write perl code when using flock, to avoid said lockups..and the code sometimes looks like the martians have landed. the flock perldoc has some of the gory details. Even with all the contrived code, the possibility of deadlock is still real, and hence it's probably better to avoid the situation altogether.
i'm sure some of the higher order perlmonks have memorised the particular idioms/code to use, and can write pretty stable code to share a file. personally i don't think it's best practice to share a file via a locking mechanism.
the hardest line to type correctly is: stty erase ^H

Start by understanding http://en.wikipedia.org/wiki/File_locking.

(Consider rewriting the code to use three-argument open and variables instead of barewords as file handles.)

What really happens is that you voluntarily protect the code between flock S and close S. flock S will block (not return) until no other process has a lock on the semaphore file. The data file is not locked at all, and as long as all processes accessing the data file agree to lock the semaphore file instead, it does not have to be locked. Locking the semaphore file guarantees that only one process per machine can access the file.

Alexander

It would be a very nice thing if Unix did implement mandatory locking, but it doesn’t.   You can use other mechanisms to safeguard cooperating processes, but you generally can’t extend the same courtesy to “outside” apps.   Very unfortunate, but true.