Re: Shared memory

Martijn van Oosterhout wrote:
> On Fri, Mar 24, 2006 at 11:51:30AM +0100, Thomas Hallgren wrote:
>
>> Hi,
>> I'm currently investigating the feasibility of an alternative PL/Java
>> implementation that would use shared memory to communicate between a JVM
>> and the backend processes. I would very much like to make use of the
>> routines provided in shmem.c but I'm a bit uncertain how to add a segment
>> for my own use.
>>
>
> I'm wondering if a better way to do it would be similar to the way X
> does it. The client connects to the X server via a pipe (tcp/ip or unix
> domain). This is handy because you can block on a pipe. The client then
> allocates a shared memory segment and sends a message to the server,
> who can then also connect to it.
>
> The neat thing about this is that the client can put data in the shared
> memory segment and send one byte through the pipe and then block on a
> read. The JVM which has a thread waiting on the other end wakes up,
> processes the data, puts the result back and writes a byte to the pipe
> and waits. This wakes up the client who can then read the result.
>
> No locking, no semaphores, the standard UNIX semantics on pipes and
> sockets make sure everything works.
>
> In practice you'd probably end up sending small responses exclusively
> via the pipe and only use the shared memory for larger blocks of data
> but that's your choice. In X this is mostly used for image data and
> such.
>
>

Pipes could be used when the connection is initialized, that's for sure.
Thanks for the suggestion. Only thing I need to solve is how to detect
if the JVM is present and start it up when it isn't. Either I require
that it's there and generate an error when it isn't (analog with what
Apache would do if Tomcat is missing) or I treat the failure to obtain
the pipe as an indication on that it's not started yet.

>> My questions are:
>> 1. Do you see something right away that invalidates this approach?
>>
>
> Nothing direct, though a single segment just for finding the JVM seems
> a lot. A socket approach would work better I think.
>
>
For the initial setup, sure. But I think pipes might be too slow for the
actual function calls. What I want is the absolute most efficient ipc
mechanism that can be achived. I'm thinking in terms of critical
sections obtained using spinlocks and atomic exchange on memory that
perhaps migrate to a real semaphore when the spin goes on for too long.

I will do some tests using pipes too. If the gain using other types of
concurrency control is second to none, then I would agree that pipes are
simpler and more elegant.

>> 2. Is using the shared memory functionality that the backend provides a
>> good idea (I'm thinking shmem functions, critical sections, semaphores,
>> etc.). I'd rather depend on them then having conditional code for different
>> operating systems.
>>
>
> That I don't know. However, ISTM a lock-free approach is better
> wherever possible. If you can avoid the semaphores altogether...
>
>
Lock free? I'm not sure I understand what you mean. I'll have to wait on
something. Or are you referring to the pipe approach?

>> 3. Would it be better if the Postmaster allocated the global segment and
>> started the JVM (based on some config parameter)?
>>
>
> I don't know about the segment but the postmaster should start. I
> thought the tsearch guys had an approach using a co-process. I don't
> know how they start it up but they connected via pipes.
>
>
I'll check that out. Thanks for the tip.

> Hope this helps,
>
Your insights often do. Thanks a lot.

Regards,
Thomas Hallgren