inter-process mutexes

Discussion in 'Java' started by horos11@gmail.com, Mar 20, 2009.

  1. Guest

    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
     
    , Mar 20, 2009
    #1
    1. Advertising

  2. Mark Rafn Guest

    <> wrote:
    >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.
    --
    Mark Rafn <http://www.dagon.net/>
     
    Mark Rafn, Mar 20, 2009
    #2
    1. Advertising

  3. Guest

    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


    On Mar 20, 3:26 pm, Mark Rafn <> wrote:
    > <> wrote:
    > >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.
    > --
    > Mark Rafn        <http://www.dagon.net/>  
     
    , Mar 21, 2009
    #3
  4. Lew Guest

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


    Please do not top-post.

    --
    Lew
     
    Lew, Mar 21, 2009
    #4
  5. Jon Gómez Guest

    wrote:
    > 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.
     
    Jon Gómez, Mar 21, 2009
    #5
  6. Tom Anderson Guest

    On Fri, 20 Mar 2009, wrote:

    > 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

    > On Mar 20, 3:26 pm, Mark Rafn <> wrote:
    >> <> wrote:
    >>> 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.


    --
    Big Bang. No god. Fadeout. End. -- Stephen Baxter
     
    Tom Anderson, Mar 21, 2009
    #6
  7. Tom Anderson Guest

    On Sat, 21 Mar 2009, Tom Anderson wrote:

    > On Fri, 20 Mar 2009, wrote:
    >
    >> 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


    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

    --
    NTK now entirely filled with google links -- NTK
     
    Tom Anderson, Mar 25, 2009
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. izik l
    Replies:
    4
    Views:
    6,596
    Mike Smith
    Jan 17, 2005
  2. Jan Danielsson

    Question about mutexes

    Jan Danielsson, Jun 1, 2005, in forum: Python
    Replies:
    2
    Views:
    380
    Jan Danielsson
    Jun 1, 2005
  3. Replies:
    7
    Views:
    384
    Earl Purple
    Jun 13, 2006
  4. Replies:
    2
    Views:
    500
  5. Replies:
    7
    Views:
    313
    Keith Thompson
    May 23, 2008
Loading...

Share This Page