inter-process mutexes

[horos11]

All,

I was wondering if there was a nice, standard, open, inter-process
mutex that I could grab for java (rather than needing to programming
it myself).

It should be heavy-weight (either shared file, or shared memory) and
allow for both a timeout, and a queue (so that incoming processes can
see where they are in line before accessing). If there was a way to
make synchronized do this, that'd be great, but I'm not picky -
manually constructing and using the object should be fine.

Anyways, looking through this list and through the docs, I don't see
anything that sticks out as 'standard'... Any ideas would be greatly
appreciated..

Thanks,

Ed

 

[Mark Rafn]

I was wondering if there was a nice, standard, open, inter-process
mutex that I could grab for java (rather than needing to programming
it myself).

Can't be done in pure Java - there's too much OS variation. You're looking at
JNI, and picking a system that works for the set of OSs you care about.

HOWEVER, this is very often the wrong granularity; almost as soon as
you've got inter-process working on the same box, you'll be asking to
synchronize across machines in a network.

Which leads to using even heavier-weight solutions, very often a transactional
RDBMS or something like terracotta. Most of the time, I'd recommend starting
with a multi-machine plan rather than coding up a multi-VM-one-machine
solution and realizing later you need to scrap it.

 

[ed.peschko]

hmm.. that explains why there isn't a standard, but I would think that
you could have something close by deciding that you will implement
your mutex/semaphore based on something lowest common denominator like
files (which would be fine for my purposes). Scalability and multiple
box handlings could be done by relying on a SAN or other such high
speed network.

I realize that this would be relatively slow, but it would be
effective. Using an RDBMS would be fine too.

Anyways, I'm hesitant to program anything like this if it exists, so
let me rephrase the question - is there a pragmatic, open platform
that does something like this, which is mostly free of warts and
supports a large subset of OSes?

Ed

 

[Lew]

hmm.. that explains why there isn't a standard, but I would think that

Please do not top-post.

 

[Jon Gómez]

hmm.. that explains why there isn't a standard, but I would think that
you could have something close by deciding that you will implement
your mutex/semaphore based on something lowest common denominator like
files (which would be fine for my purposes). Scalability and multiple
box handlings could be done by relying on a SAN or other such high
speed network.

I don't know much about this kind of thing, but for file locking, I saw
there is a java.nio.channels.FileLock class, even if it is totally at
the mercy of the OS variation mentioned by Mark. So there is a lowest
common denominator of the kind of you mentioned (for the systems with
exclusive file locking), but I don't know if anyone has built on it or
if it's really even that good an idea. I plead ignorance .

Jon.

 

[Tom Anderson]

hmm.. that explains why there isn't a standard, but I would think that
you could have something close by deciding that you will implement your
mutex/semaphore based on something lowest common denominator like files
(which would be fine for my purposes). Scalability and multiple box
handlings could be done by relying on a SAN or other such high speed
network.

I realize that this would be relatively slow, but it would be effective.
Using an RDBMS would be fine too.

Anyways, I'm hesitant to program anything like this if it exists, so let
me rephrase the question - is there a pragmatic, open platform that does
something like this, which is mostly free of warts and supports a large
subset of OSes?

You may want a lock manager:

http://en.wikipedia.org/wiki/Distributed_lock_manager

There are a couple in Linux, but i can't vouch for their suitability for
your purposes. In particular, i have no idea if there's a java interface.

If you wanted to work on a single machine, and didn't need the complex
behaviour you mentioned (like being able to see where you were in the
queue), then i'd say use file locks; file locks vary a lot across systems,
but all modern OSs, including Windows, support lock semantics sufficient
to implement read/write locks between cooperating processes. A solution
using file locks would be simple, efficient and robust.

As soon as you want to go over a network, though, you're shafted. You
could do file locks on an NFS-shared volume, but i wouldn't want to rely
on it. I guess you could use the same approach on a WebDAV server, using
its file locks as mutexes.

As Mark mentioned, there's Terracotta:

http://javathink.blogspot.com/2008/12/java-distributed-lock-manager.html

Which looks a bit scary.

tom

 

[Tom Anderson]

You may want a lock manager:

http://en.wikipedia.org/wiki/Distributed_lock_manager

I was thinking about this a bit more after i posted. If you can get what
you want from file locks, use those. If you can't, forget third-party
solutions or other cleverness, and write your own. Access it via RMI.

The thing is, a lock manager of the kind you want is actually a pretty
simple component. Two or three classes, a couple of hundred lines of code,
tops. It'd be quicker to write exactly the thing you want than to spend
ages searching for something already written, and then customising the
not-quite-right thing you found.

tom