Re: Shared memory IPC using NIO memory-mapped files -- anyone done this?

I've been thinking more about using shared memory vs. memory mapped files.

On Windows, it appears shared memory is just a memory mapped file backed by
the swap file. This is not true for Linux where plain shared memory is
faster.

Back to using this to implement IPC... let's assume we have N processes each
of which are passing M interprocess messages.

With plain shared memory, you can just allocate and share N * M blocks on
the fly. Easy.

With a memory mapped file, I can think of two approaches: using 1 file or N
* M files. Using 1 file would probably yield the performance Randall says
you can get, but you would have to implement your own heap management
algorithms. It seems to me you should just use plain shared memory and leave
heap management to the OS.

I'm pretty sure creating N * M file (i.e. just creating a new file for each
transaction) would surely touch the disk every time which you definitely
don't want.

Is there another solution?

Bob

On 8/18/07, Randall R Schulz <[email protected]> wrote:
>
> On Saturday 18 August 2007 09:59, Bob Lee wrote:
> > On 8/18/07, Randall R Schulz <[email protected]> wrote:
> > > In any decent operating system, memory-mapped file pages are kept
> > > in core as much as other concurrent file access and RAM demand
> > > allows. Assuming one's (system-wide) working set does not exceed
> > > physical RAM, paging of memory-mapped file contents is probably not
> > > much of a problem.
> > >
> > > What's more, since the kernel manages memory globally, it can
> > > optimize with more comprehensive information than any single
> > > process (easily) could.
> >
> > It's not a RAM disk. It still has to write the data to disk which you
> > don't want when you're just passing data between processes.
>
> No, it does not. The kernel is free to delay writes as long as it likes.
> And even when it does write a page, it does so asynchronously.
> Write-behind (and read-ahead) is essential to ordinary file I/O and
> they apply equally well when the file's contents are mapped into a
> segment of RAM. In fact, even better, since there's no need to copy
> from one address space to another as their is with ordinary writing
> (or, for that matter, with network and other device I/O).
>
> Certainly, some access patterns will be more problematic and harder for
> the VM system to cope with than others, but if you're sharing data
> among several processes, a memory-mapped file (fragment) is a very
> efficient way to do it.
>
>
> > Bob
>
>
> Randall Schulz
>
> ===================================
> This list is hosted by DevelopMentor(r)  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com
>

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com