in reply to locking over the network

If the order of reads and writes is independent and you simply want to ensure you have a consistent read, you could try having the writer write to a temp file, unlink the real file, and then rename that temp file to the real name.

Would the unlink and rename be sufficiently atomic for your purpose?

Replies are listed 'Best First'.
Re^2: locking over the network
by rovf (Priest) on Jan 31, 2011 at 17:15 UTC
    On writing, only one string is written to the file. The next time we are coming to the write operation, the old content is discarded and the new string is written.

    However, I see one problem with your solution: There is a race condition between unlinking the original file, and renaming the temp file. If process B tries to access the file during this time, it thinks there is no such file. Unfortunately, having no file *is* a legal situation (and, from the processing logic, equivalent to an empty file), so we can not let the reader wait until the file appears.

    -- 
    Ronald Fischer <ynnor@mm.st>
[reply]
[d/l]
      Unfortunately, having no file *is* a legal situation (and, from the processing logic, equivalent to an empty file)

      Then change the logic, and make no file different to an empty file. That is, make it so that the create always creates a file, even if that file is empty. That way, your reader will always wait until there is a file before deciding upon its next action.

      Having the absence of a file be logically equivalent to the presence of an empty file creates the situation where the reader takes the crash of the writer to mean the same thing as the writer creating an empty file. And that's just silly. It just creates a false dilemma.

      With locking, the reader would have to wait for the writer to unlock the file. This will normally be a short period, but could potentially be forever if the creator crashed whilst holding the lock.

      If the reader waits (with timeout) for the appearance of the file you have the same situation.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

      rename is atomic (and overwrites) on most common Perl platforms.

      - tye        

[reply]
        I didn't consider rename, because rename says:

        ... it will usually not work across file system boundaries, even though the system mv command sometimes compensates for this.

        As for atomicity, I wonder how Perl could guarantee that, without assumption of the file system being used. Unfortunately I don't know enough about Samba, CIFS and NFS, to know what they offer for atomic rename. May I ask you where you got the information that rename is atomic?
        -- 
        Ronald Fischer <ynnor@mm.st>
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom