Shared memory in .NET and WCF

[Oriane]

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

 

[Michael Nemtsev]

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>

 

[Willy Denoyette [MVP]]

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.

 

[Leon Lambert]

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]

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

 

[Oriane]

Hello Willy,

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

 

[Oriane]

Hello Michael,

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

 

[ronscottlangham]

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

 

[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()) ?

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

 

[ronscottlangham]

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...




I thought that WCF was a superset of remoting, an that what remoting can do,
so can WCF ?


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

 

[per9000]

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

I don't know if this helps but: you might want to befriend
GC.KeepAlive.

/Per

--

Per Erik Strandberg
home: www.pererikstrandberg.se
work: www.incf.org
also: www.spongswedencare.se