Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #11741 > unrolled thread

Re: Interplatform (interprocess, interlanguage) communication

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Interplatform (interprocess, interlanguage) communication Roedy Green <see_website@mindprod.com.invalid> - 2012-02-04 12:50 -0800
    Re: Interplatform (interprocess, interlanguage) communication Roedy Green <see_website@mindprod.com.invalid> - 2012-02-04 13:22 -0800
      Re: Interplatform (interprocess, interlanguage) communication Jan Burse <janburse@fastmail.fm> - 2012-02-04 22:33 +0100
        Re: Interplatform (interprocess, interlanguage) communication Roedy Green <see_website@mindprod.com.invalid> - 2012-02-12 04:30 -0800
      Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-04 18:42 -0500
    Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-04 18:39 -0500

#11741 — Re: Interplatform (interprocess, interlanguage) communication

On 3 Feb 2012 19:52:08 GMT, ram@zedat.fu-berlin.de (Stefan Ram) wrote,
quoted or indirectly quoted someone who said :

>  When an X process and a Java process have to exchange
>  information on the same computer, what possibilites are
>  there?

TCP/IP socket.

both talk to SQL database, presume data cached.

both read and write same file on SSD

JNI
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
One of the most useful comments you can put in a program is 
"If you change this, remember to change ?XXX? too".
 

[toc] | [next] | [standalone]

#11742

On Sat, 04 Feb 2012 12:50:15 -0800, Roedy Green
<see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :


>both read and write same file on SSD

Let's say you used a simple RandomAccessFile.  How could you implement
a busy lock field in the file to indicate the file was busy being
updated? or busy being read?  In RAM you have test and set locks to
check a value and set the value in one atomic operation.  How could
you simulate that without test and set hardware on the SSD? You can't
very well share a RAM lock between separate jobs.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
One of the most useful comments you can put in a program is 
"If you change this, remember to change ?XXX? too".
 

[toc] | [prev] | [next] | [standalone]

#11743

Roedy Green schrieb:
> Let's say you used a simple RandomAccessFile.  How could you implement
> a busy lock field in the file to indicate the file was busy being
> updated? or busy being read?  In RAM you have test and set locks to
> check a value and set the value in one atomic operation.  How could
> you simulate that without test and set hardware on the SSD? You can't
> very well share a RAM lock between separate jobs.

What do you want, a write lock or a read lock?
Here is a write lock:

Obtain the lock:
                 raf = new RandomAccessFile(file, "rw");

                 fo = new FileOutputStream(raf.getFD());
                 fo.getChannel().lock(0, Long.MAX_VALUE, false);

Release the lock:
                 fo.close();

		raf.close();

Maybe it can be done even simpler, but the above
works for me over process / jvm boundaries. Can
be also used to synchronize jvm with non-jvm code.

Similar code I use to obtain a read lock, via an
FileInputStream and the lock() methods third
argument =true. Currently seems also to work on
Android, but did not yet thoroughly test...

Bye

(*)
http://docs.oracle.com/javase/1.4.2/docs/api/java/nio/channels/FileChannel.html#lock%28long,%20long,%20boolean%29

[toc] | [prev] | [next] | [standalone]

#11971

On Sat, 04 Feb 2012 22:33:23 +0100, Jan Burse <janburse@fastmail.fm>
wrote, quoted or indirectly quoted someone who said :

>Obtain the lock:
>                 raf = new RandomAccessFile(file, "rw");
>
>                 fo = new FileOutputStream(raf.getFD());
>                 fo.getChannel().lock(0, Long.MAX_VALUE, false);
>
>Release the lock:
>                 fo.close();

 That is quite a bit of overhead. I would work fine for low traffic. I
was hoping for something that would let you leave the file open in
both jobs. e.g. a reserved block or blocks in the file that the
intercommunicators read and wrote to lock.  I suppose you could send
messages to a task that owned the file (a primitive database), but
then you might as well send messages directly to each other.

-- 
Roedy Green Canadian Mind Products
http://mindprod.com
One of the most useful comments you can put in a program is 
"If you change this, remember to change ?XXX? too".
 

[toc] | [prev] | [next] | [standalone]

#11748

On 2/4/2012 4:22 PM, Roedy Green wrote:
> On Sat, 04 Feb 2012 12:50:15 -0800, Roedy Green
> <see_website@mindprod.com.invalid>  wrote, quoted or indirectly quoted
> someone who said :
>> both read and write same file on SSD
>
> Let's say you used a simple RandomAccessFile.  How could you implement
> a busy lock field in the file to indicate the file was busy being
> updated? or busy being read?  In RAM you have test and set locks to
> check a value and set the value in one atomic operation.  How could
> you simulate that without test and set hardware on the SSD?

java.nio.channels.FileLock with the caveats about what the OS
supports.

>                                                              You can't
> very well share a RAM lock between separate jobs.

You can in most OS. It is just not well supported in Java.

Arne

[toc] | [prev] | [next] | [standalone]

#11747

On 2/4/2012 3:50 PM, Roedy Green wrote:
> On 3 Feb 2012 19:52:08 GMT, ram@zedat.fu-berlin.de (Stefan Ram) wrote,
> quoted or indirectly quoted someone who said :
>
>>   When an X process and a Java process have to exchange
>>   information on the same computer, what possibilites are
>>   there?
>
> TCP/IP socket.
>
> both talk to SQL database, presume data cached.
>
> both read and write same file on SSD
>
> JNI

If you had bothered read the entire post, then you may have
been able to avoid repeating those already listed in the
post.

Arne

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web