In the context you are showing this is safe and effective. I just wanted to mention a couple of things relating to the open mode you are using, ">". In your use-case, the semaphore file is safe. But if someone were to come along and look at this as how to open an output file they could be exposing themselves to a nasty race condition. Also, a common idiom in using a semaphore lock file for highlander control is to write the lock-holder's PID into the lockfile. In both cases, the ">" open is risky.

Here's the scenario:

  1. First process opens an output file, obtains a lock, and writes something into the file.
  2. Second process opens the same output file, but fails to obtain a lock because the first process holds the lock. However, because the file was opened in ">" mode, the file's contents were truncated to zero. So the process that failed to obtain a lock modified the file that some other process had a lock on before attempting to get a lock.

It is sometimes useful to write a PID into a lockfile so that it is easier for an observer to know who holds the lock, or who is manipulating the file. This isn't strictly necessary; it's informative. I could, as an outsider to the software, come along and look, seeing that myscript.LOCK contains the pid 6327. I can look and see if that PID is still alive, how long it's been running, how much memory it's using, and so on. There are other ways to discover who holds a lock, but just looking at a PID written into a file is an easy way. For that to work reliably, however, it is necessary that nobody opening the file modify it in any way before obtaining a lock. open my $fh, '>', $lockfile modifies the file before there's an opportunity to lock it.

There are strategies for preventing this situation. One is to use sysopen for finer-grained control; open with O_CREAT but without O_TRUNC, for example. Another option is to open in append mode. I've used both. If opening in append mode, with the intent of clobbering the content of the file after obtaining a lock, it would be necessary to seek to the beginning and truncate manually after obtaining the lock, before writing into the file. One reason for using sysopen would be if you want the call to fail entirely if the file already exists: O_CREAT|O_EXCL.

There's an MJD talk, the slides for which are really useful: File Locking Tips and Traps. In those slides, "+<" is used.

I think I gave a YAPC talk on flocking a few years back that may also provide some explanation: https://youtu.be/tWdmxrtPiKs.

Anyway, the point to this follow-up is please don't open in '>' mode and then obtain a lock, if you care about the contents of the file, because if you fail to get the lock because someone else holds it, you just stomped on them.


Dave

In reply to Re: File lock demo by davido
in thread File lock demo by LanX

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.