Re: [VW] file locking

I guess that on Windows you already have sufficient locking as-is.

On Un*x the simplest thing to implement would be separate lock files. You can implement this with normal file operations (so it is guaranteed to work on all Un*x flavors).

I forgot the exact algorithm so you'll have to search for it. I recall it being pretty simple to implement, the only problem being that it is not robust when applications crash (stale lock files hanging around).


I also came across the following hack:
----
Here is a nice lock implementation that works both on UNIX and WIN32 platforms. It's done using sockets (IPC). Basicly, the idea here is to open a server socket on a particular port. This will fail if the port is already in use. So this little trick allows us to manage locks without having to resort to lock files. In this sample implementation you can even supply LOCK ID's that will be mapped to 'unique' port numbers (done here by using a simple hash function). The nice thing about this method is that it's 100% fool-proof. The O/S will guarantee that only one process can actually open a port. As a nice bonus, the O/S will also auto-release the lock if your process dies. This works OK on both UNIX and WIN32 platforms! There is one small caveat. If you open a socket (ie: aquire the lock), and then use 'exec' to spawn a process, than your new child process will inherit the 'open' socket. So if that process (or some of it's child processes) would remain to run, even after you long closed 'your' socket, than the socket will still be considered open. In fact, you wouldn't be able to open that socket while the child processes remain to hold the socket open! Something to be aware off...
---- (http://wiki.tcl.tk/593)


HTH,

R
-


Ian Upright wrote:
Reinout Heeck <reinout@xxxxxxxx> wrote:

Ian Upright wrote:
I must be missing something somewhere, because I can't seem to find how I
lock a file for exclusive access in VW?
This is not directly supported by VW and both OS and file system dependent. Typically locking on network shares is not reliable.

Which OS are we talking about?

R

:-( I'm not looking for page-level locking over a network share, just exclusive access so the file can't be modified by two processes on the same machine.

The platforms I need are Windows, Linux, Linux64, OSX and possibly others.
Ok, well it's good to know that it's not supported and I wasn't just missing
it somewhere.

I/we may be building a cross-platform cross-dialect file i/o library at some
point, as part of http://commonsmalltalk.wikispaces.org anyways.
Unfortunately, it seems libraries like www.wxwidgets.org don't even do cross
platform locking! Hmmm.

Ian

---
http://www.upright.net/ian/
.

Relevant Pages

  • Re: Handling locked db tables...
    ... When choosing a port the table is read and the first available ... When I run a "lock table mytable read" I can do all of my ... This is normal database locking behavior. ... using an indicator that's unique to the process/thread requesting the ...
    (comp.lang.python)
  • Network Stack Locking
    ... things like locking strategies in this e-mail. ... "Network Stack Locking" task of SMPng. ... Additional work is taking place to explore socket locking issues in: ... acquire Giant without generating a lock order issue. ...
    (freebsd-arch)
  • Re: kqueue disable on delivery...
    ... The first is EV_DOD, aka disable on delivery. ... some in-kernel lock overhead. ... necessity to guarantee that the socket (both events - EVFILT_READ ... use the oneshot only model where a socket is deleted from port on delivery. ...
    (freebsd-arch)
  • Re: kqueue disable on delivery...
    ... The first is EV_DOD, aka disable on delivery. ... some in-kernel lock overhead. ... necessity to guarantee that the socket (both events - EVFILT_READ ... use the oneshot only model where a socket is deleted from port on delivery. ...
    (freebsd-current)
  • Re: Server overloaded? Or is it a bug?
    ... > and socket were fully allocated, and the socket was returned by the kernel ... > classes of things that look like deadlocks: ... > holding a vnode lock when the NFS server ceases to respond. ...
    (freebsd-stable)