11

I'm currently using shared memory for IPC between Java and C++ apps, but looking for a more convenient alternative.

Can someone advise a better method with same performance and speed?

Thanks!

andersoj
  • 22,406
  • 7
  • 62
  • 73
SyRenity
  • 841
  • 5
  • 11
  • 18

5 Answers5

7

It depends on how you plan to have your apps interact. In the POSIX environment, you have pipes, shared memory, sockets, semaphores and message queues. See this question: Comparing unix linux IPC for more information.

What is the interaction model for your processes (i.e. client/server, producer-consumer, etc)?

From personal experience, I would suggest your best bet would be pipes (since they are just files to read and write bytes) or sockets (since both languages support them).

Community
  • 1
  • 1
mikelong
  • 3,694
  • 2
  • 35
  • 40
5

As mikelong said, this depends a lot on what you are doing. AFAIK, none of the IPC methods have native Java bindings, so you're probably going to have to use JNI and make bindings yourself, so all the different methods are roughly equally as hard. If you are doing message passing though, I highly suggest using message queues. They are very easy to use (once you have the bindings), and have good performance. If you need to "share" some resource, then you probably want to stick with shared memory.

As it sounds like you are having some sort client/server thing, I would say use either message queues, unix domain sockets, or named pipes. They all involve copying data in the kernel, so they are not quite as fast as shared memory, but they are still very fast. If you have message-like data (individual small packets), go with message queues. That is probably the cleanest solution. If you have more of a stream of data, use pipes or sockets. Sockets have the advantage that you can easily make it network transparent (like X11) later on if you want, but they are slightly harder to work with than pipes. The performance is probably very similar.

Zifre
  • 26,504
  • 11
  • 85
  • 105
  • Only looking to move some binary data - but as fast as possible. – SyRenity May 24 '09 at 20:11
  • I'm actually using JNA for IPC and it works fine - but again, the general inconvenience of shared memory (segments leftover, etc...) are a killer. – SyRenity May 24 '09 at 20:12
  • Does Java support Unix domain sockets? You may need an add-on lib for that. If your data consists of a few fixed structures go with message queues. They are fast and easy to use. If the data is more variable and stream-like then go with named pipes. – Duck May 25 '09 at 02:02
  • Are named-pipes have same or very closed speed to shared memory? – SyRenity May 25 '09 at 09:18
  • named pipes (fifos) are going to be slower than shared memory but that doesn't mean they aren't within tolerable limits for your app. Since you have multiple writers and one reader you are probably doing a lot of locking now. If your data is less than PIPE_BUF (usually around 4k) then your writes from various processes will be atomic and managed by the OS so that complexity is removed from your pgms. Alternatively you can have each writer use its own FIFO and multiplex your reader with something like select(). – Duck May 25 '09 at 14:53
  • Actually I use a circular buffer in shared memory, which allows me to not require any locking at all. AFAIK this possible only in shared memory - but perhaps mmap can do it it? Dunno about pipes or sockets at this department. – SyRenity May 25 '09 at 17:37
0

While likely not the most efficient, Java only supports sockets out of the box (the best I recall). They are very flexible, just perhaps not as fast as other options. As Zifre mentioned, it leaves you with an opportunity for network transparency, as well as language/binding transparency; as pretty much every language supports a socket library out of the box these days.

While I am throwing efficiency out of the window, if you wish to take it to the next level, you could probably wrap this in a Web Service of some kind. Use an embedded web server on the consumer for the producers to submit their data to.

monceaux
  • 596
  • 2
  • 5
0

The easiest way to communicate between applications written in different languages is IMHO CORBA. There are very good open source CORBA ORBs out there. We use TAO for C++ and JacORB for Java. There are also companies like OCI and Remedy that provide technical support.

lothar
  • 19,853
  • 5
  • 45
  • 59
  • CORBA would be overkill in this situation IMO. Its easy to forget how much work goes into setting up the ORBs, learning CORBA, IDL, etc. It's a daunting prospect for someone who just wants to pass some data on the same machine, much of it unstructured which is a bit of a PITA in CORBA. – Duck May 26 '09 at 22:02
  • @Duck in my experience it's easier to learn how to use CORBA than to do cross language/platform communication manually correctly. Just to get all the marhalling/demarshalling right can be a nightmare. Not to mention all the nice services (naming, event, ...) that one can use out of the box. – lothar May 26 '09 at 23:26
  • 1
    Are you serious?? COBRA? In 2012? I'm sure it's a nice technology and the fact that it's dead is unfortunate and sad, but it's still dead. – MK. Apr 10 '12 at 03:02
-6

I'm currently using shared memory for IPC between Java and C++ apps, but looking for a more convenient alternative.

Can someone advice better method, but with same performance speed?

For simple shared memory you don't even need a special library:

class Main {
    private static class CustomThread extends Thread {
        public int x = 0;
        public void run() {
            x = 5;
        }
    }

    public static void main(String[] args) {

        CustomThread t = new CustomThread();
        t.start();

        System.out.println(t.x);
        System.out.println(t.x);
    }
}

The local variable x be accessed outside the thread and within, allowing you to use it to pass information in and out of the thread.

zjagannatha
  • 336
  • 2
  • 5