use Storable;
use Fcntl qw(:flock)

sub _store {
    my $data = shift;
    my $data_file = 'data/plugin_portfolio';

    store $data, $data_file;
    close LOCK;
}

sub _retrieve {
    my $data_file = 'data/plugin_portfolio';
    return 0 if !-f $data_file;

    my $lock = $data_file . '.lck';
    open (LOCK, "> $lock") or die "Can't open lock file";
    flock(LOCK, LOCK_EX);

    retrieve $data_file;
}
[download]

Not pretty.

• Two-argument open was already mentioned in Re: Will these functions for use with Storable properly lock my file?. Use three-argument open.
• Don't use bareword file handles. They are truely global and may collide with other (legacy) code using bareword file handles. Use lexical file handles.
• _retrieve() leaks the bareword file handle LOCK, the lock file is kept locked until some other code explicitly closes that handle.
• _store() closes a bareword file handle never opened there.
• Are the previous two points intentional? Spooky action at a distance?

Regarding the last point: I did not look up the Storable API, so maybe Storable explictly requires this behaviour? Does Storable guarantee that _retrieve() and _store() are always in this order, and never alone? If so, the code lacks a clear comment indicating that behaviour.

I would expect Storable to call either _store() or _retrieve(), but not both. In that case, your code effectively locks only when you read first, but then until you end the process, read again, or write.

If you have two instances running in parallel, and one chooses to read, then do a lot of other stuff, the other instance will fail to get the lock even if the first instance has finished reading long ago. At least, in this situation you won't loose data. But you effectively have only one working process at any time.

If you have two instances running in parallel, and one chooses to write (calling _store()) without prior read, while the other chooses to read (calling _retrieve()), the writer will simply damage the data on disk while the reader assumes to be safe because it holds a lock. The writer doesn't even get an error, because close lacks error checks. Instant loss of data. (And trust me in that regard, Murphy will make sure that your data is damaged at the most inconvienient moment in time, causing the maximum damage.)

davido++ explains in Re: Will these functions for use with Storable properly lock my file? that Storable already has code for file locking. If that was not so, you should lock both reading and writing, each time using a lexical file handle that is implicitly unlocked and closed when you leave the reading and writing routines. That way, only one process can ever hold a lock for the data file, and it will hold the lock only as long as absolutely needed.

Alexander