Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re: singleton lock not reliable

by davido (Cardinal)
on Jun 25, 2021 at 22:23 UTC ( [id://11134303]=note: print w/replies, xml ) Need Help??


in reply to singleton lock not reliable

I keep coming back to my first thought, which I dismiss as "that's too easy." But since it keeps entering my mind I'll mention it:

What if you have two instances of the script itself on your filesystem? Is it possible that your cron invokes a script at one path, and your testing invokes a script in ~/bin/ for example? They would be separate files, so totally different locks.

I did toy with the relative path consideration, but could never reproduce a situation where invocations from different working directories (hence, different relative paths, but the same absolute path) would result in different locks. If there's only one file that you're running, it's going to be the same thing being locked.


Dave

Replies are listed 'Best First'.
Re^2: singleton lock not reliable
by afoken (Chancellor) on Jun 26, 2021 at 13:06 UTC
    I did toy with the relative path consideration, but could never reproduce a situation where invocations from different working directories (hence, different relative paths, but the same absolute path) would result in different locks. If there's only one file that you're running, it's going to be the same thing being locked.

    After all, the OS is supposed to resolve the paths to a file, probably a device ID and an inode on Unixes. So all ways to name the same file should end up with the same file.

    I think there is a way to obtain two different locks on a single file. It is a very constructed example, and quite silly to use in the real world. The trick is to make the operating system on our machine think we would try to lock two different files.

    Let's assume that locking "just works" over the net for every single protocol used below. In the real world, this is not always the case.

    Let's put the file to be locked on a fileserver. Export the filesystem on which the file is stored via some protocol to our computer. Locking still works fine with this setup. Now, choose a second protocol to mount the same server filesystem again on a different mount point. Using only the second mount point, locking should still work fine.

    Now, what happens when we use both mount points, i.e. both protocols, to try to lock our file?

    Ideally, both protocol implementations would just transparently pass any locking request to the server's operating system. Nothing would change, except for some overhead, so only one process on our computer could obtain a lock.

    But if at least one protocol implementations implement their own file locking mechanism, and we would try to lock the file using both mount points, neither of the protocol implementation would know about the other one's locks, and so two independent locks could be obtained for the same file.

    The same construct should also work if one protocol is local filesystem access and the other one is a network protocol via the loopback interface that implements its own locking. It should also work with a user-space filesystem implementation (e.g. FUSE) that implements its own locking on top of a local filesystem in place of the network protocol via the loopback interface.

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://11134303]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others surveying the Monastery: (4)
As of 2024-03-29 11:22 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found