Shared memory in .NET and WCF

Hello,

I have to share a object in RAM between several processes. I intend to
design a special process to load this objet (an Autocad plan) in memory, and
to take care of the read/write operations made by the other processes with
WCF based on named pipes.

Would you think it is a good idea ?

Best regards

Oriane

Hello Oriane,

so, as I understand it's like the caching, right?

I see no evil in this. The similiar approach is used widely in win32 world
and names MMF.
You only need to worry about thread safing when accessing your object.

---
WBR, Michael Nemtsev [.NET/C# MVP].
My blog: http://spaces.live.com/laflour
Team blog: http://devkids.blogspot.com/

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

O> Hello,
O>
O> I have to share a object in RAM between several processes. I intend
O> to design a special process to load this objet (an Autocad plan) in
O> memory, and to take care of the read/write operations made by the
O> other processes with WCF based on named pipes.
O>
O> Would you think it is a good idea ?
O>
O> Best regards
O>
O> Oriane
O>

"Oriane" <oriane@guermantes.fr> wrote in message
news:10E865CF-F9BE-4297-8538-A271DA2BF6BE@microsoft.com...
> Hello,
>
> I have to share a object in RAM between several processes. I intend to
> design a special process to load this objet (an Autocad plan) in memory,
> and to take care of the read/write operations made by the other processes
> with WCF based on named pipes.
>
> Would you think it is a good idea ?
>
> Best regards
>
> Oriane
>


Not sure what you mean here, "Named pipes" and "shared memory" are different
beasts! Named pipes are not wrapped by the Framework, so you will have to
use PInvoke to call the native shared memory API's. WCF offers remoting
features over named pipes, , these 'Pipe' channels are actually mapped over
shared memory files, this is by far the fastest way to share data across
processes.

Willy.

Using common data between processes via shared memory is a fairly common
thing to do. It can be very difficult to get right if this is your first
attempt. Things like concurrency are hard to get right. Also be advised
that accessing data via pointers can also be difficult. If you are
dealing with a large shared pool it might get hard to find memory in
every process that maps to the exact same address. In our case the
entire pool can be mapped where ever the OS puts it within the process
and all pointer types within the pool are actually offsets. The
applications computer the pointers on the fly by adding the offset to
start of the pool. If you are dealing with small pools this probably
won't be a problem. Memory compaction can be another problem. If you
allocate and deallocate objects in your pool it can get fragmented.
Dealing with this fragmentation can get tricky for a novice. It took
me a couple of years to get our shared memory real time database right.

Hope this helps.
Leon Lambert


Oriane wrote:
> Hello,
>
> I have to share a object in RAM between several processes. I intend to
> design a special process to load this objet (an Autocad plan) in memory,
> and to take care of the read/write operations made by the other
> processes with WCF based on named pipes.
>
> Would you think it is a good idea ?
>
> Best regards
>
> Oriane
>

"Leon Lambert" <lambertl@inil.com> a écrit dans le message de
news:OMlFa61pHHA.4396@TK2MSFTNGP02.phx.gbl...
> Using common data between processes via shared memory is a fairly common
> thing to do. It can be very difficult to get right if this is your first
> attempt. Things like concurrency are hard to get right. Also be advised
> [...].
> Dealing with this fragmentation can get tricky for a novice. It took
> me a couple of years to get our shared memory real time database right.
Yes that's exactly why I prefer to use WCF !!!!

Regards

Hello Willy,

"Willy Denoyette [MVP]" <willy.denoyette@telenet.be> a écrit dans le message
de news:95F36943-0407-40AE-880C-8AEFA96BEE90@microsoft.com...
>
> Not sure what you mean here, "Named pipes" and "shared memory" are
> different beasts! Named pipes are not wrapped by the Framework, so you
> will have to use PInvoke to call the native shared memory API's. WCF
> offers remoting features over named pipes, , these 'Pipe' channels are
> actually mapped over shared memory files, this is by far the fastest way
> to share data across processes.

Yes I don't want to get involved into shared memory problems, since I have
no experience about that on Windows. I really prefer to use WCF over named
pipes. If this is the fastest way to shared data across processes, it is
just perfect...

Thanks

Hello Michael,

"Michael Nemtsev" <nemtsev@msn.com> a écrit dans le message de
news:a279a63a3f5d708c975845eec346e@msnews.microsoft.com...
> Hello Oriane,
>
> so, as I understand it's like the caching, right?
>
> I see no evil in this. The similiar approach is used widely in win32 world
> and names MMF.
> You only need to worry about thread safing when accessing your object.
Ok fine !

Thanks

On Jun 5, 3:02 am, "Oriane" <ori...@guermantes.fr> wrote:
> Hello,
>
> I have to share a object in RAM between several processes. I intend to
> design a special process to load this objet (an Autocad plan) in memory, and
> to take care of the read/write operations made by the other processes with
> WCF based on named pipes.
>
> Would you think it is a good idea ?
>
> Best regards
>
> Oriane


Just to clarify, are you thinking of exposing this object via pointers
and shared memory and allow some one to have direct access to its data
from another process, or provide high-level read/write methods that
provides a data access layer to the data (e.g. GetXXX(), GetYYY()) ?

If pointers and shared memory, then this is a more complex area and
WCF doesn't do much for you in this area (in my opinion).

It sounds like you are going to be running this on the same computer
as the other processes, correct? If providing high-level methods,
you may look at .NET Remoting (http://www.developer.com/net/cplus/
article.php/1479761) this may provide a better method of sharing data
and objects across processes on the same computer than WCF.

Ron

<ronscottlangham@yahoo.com> a écrit dans le message de
news:1181047065.887168.118840@h2g2000hsg.googlegroups.com...
>
> Just to clarify, are you thinking of exposing this object via pointers
> and shared memory and allow some one to have direct access to its data
> from another process, or provide high-level read/write methods that
> provides a data access layer to the data (e.g. GetXXX(), GetYYY()) ?
I do not intend to use shared memory. An ad hoc process will load the "data"
into its heap, and implement high-level read/write methods, with of course
some locks...

>
> If pointers and shared memory, then this is a more complex area and
> WCF doesn't do much for you in this area (in my opinion).
Absolutely.

> It sounds like you are going to be running this on the same computer
> as the other processes, correct?
yes

> If providing high-level methods, you may look at .NET Remoting
> (http://www.developer.com/net/cplus/
> article.php/1479761) this may provide a better method of sharing data
> and objects across processes on the same computer than WCF.
I thought that WCF was a superset of remoting, an that what remoting can do,
so can WCF ?

> Ron
Oriane

On Jun 5, 9:11 am, "Oriane" <ori...@guermantes.fr> wrote:
> <ronscottlang...@yahoo.com> a écrit dans le message denews:1181047065.887168.118840@h2g2000hsg.googlegroups.com...
>
> > Just to clarify, are you thinking of exposing this object via pointers
> > and shared memory and allow some one to have direct access to its data
> > from another process, or provide high-level read/write methods that
> > provides a data access layer to the data (e.g. GetXXX(), GetYYY()) ?
>
> I do not intend to use shared memory. An ad hoc process will load the "data"
> into its heap, and implement high-level read/write methods, with of course
> some locks...
>
>
>
> > If pointers and shared memory, then this is a more complex area and
> > WCF doesn't do much for you in this area (in my opinion).
>
> Absolutely.
>
> > It sounds like you are going to be running this on the same computer
> > as the other processes, correct?
>
> yes
>
> > If providing high-level methods, you may look at .NET Remoting
> > (http://www.developer.com/net/cplus/
> > article.php/1479761) this may provide a better method of sharing data
> > and objects across processes on the same computer than WCF.
>
> I thought that WCF was a superset of remoting, an that what remoting can do,
> so can WCF ?
>
> > Ron
>
> Oriane

You may be right, just wanted to bring it up as an option. I was
thinking that .NET Remoting may be more friendly regarding CLR types,
state management, and callbacks, but WCF is certainly an improvement
in these areas over ASMX web services. Just may require a little more
configuration to get this all working if needed. I was thinking
that .NET Remoting may be little faster since it uses binary encoding,
but from the link below it looks like I am wrong. If you are using
the TCP, Named Pipes, etc. (anything other than HTTP), then I think
you will get binary encoding by default

http://msdn2.microsoft.com/en-us/library/bb310550.aspx

Ron