468,554 Members | 1,388 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,554 developers. It's quick & easy.

SharedMemory Base address mapping

Hi

I wonder... Is it possible to define the address to which shared memory will be mapped
In other words is it possible to apriory define the address MapViewOfFile returns
Dlls are being loaded and relocated on the relocation table during Process Creation, is it possible to use/manipulate this mechanism somehow...

Nadav.
Nov 17 '05 #1
3 1411
"Nadav" <an*******@discussions.microsoft.com> wrote in message
news:FB**********************************@microsof t.com...
I wonder... Is it possible to define the address to which shared memory will be mapped? In other words is it possible to apriory define the address MapViewOfFile returns? Dlls are being loaded and relocated on the relocation table during Process

Creation, is it possible to use/manipulate this mechanism somehow... ?

Check the docs for MapViewOfFileEx() to see if it will do what you want.

Note that in general, because a virtual address is available in one process
you can not make any claim about the same address in other.

Regards,
Will
Nov 17 '05 #2
Hi William

Thanks for your reply, I wonder... Concerning the shared mem mapping is the first thing I do on process startup, doesn't existing memory layout of multiple process may include cases where no two processes may have the same memory block mapped to the same address, e.g. a memory block of about 0.25GB is about to be mapped to the same address of several process ( using MapViewOfFileEx ), is it possible that no continues memory block at the same address ( in each process ) can be found for all process, what is the feasibility for such a scenario? I guess I would have to implement some hand-shake mechanism to achieve this task ( in case it is feasible )..

Nadav

Nov 17 '05 #3
"Nadav" <an*******@discussions.microsoft.com> wrote in message
news:17**********************************@microsof t.com...
Thanks for your reply,
You are welcome.
I wonder... Concerning the shared mem mapping is
the first thing I do on process startup, doesn't
existing memory layout of multiple process may
include cases where no two processes may have
the same memory block mapped to the same
address, e.g. a memory block of about 0.25GB is
about to be mapped to the same address of several
process ( using MapViewOfFileEx ), is it possible
that no continues memory block at the same address
( in each process ) can be found for all process, what
is the feasibility for such a scenario?
I should have been clearer but yes, it is possible that two processes may
not be able to share the same sized block at a common "virtual address". The
point is that the mapping is "per-process". Unlike the case on 9x, it is a
process' view of the shared memory which is associated with an address. On
9x, the shared memory block itself is associated with the shared address.
I guess I would have to implement some hand-shake
mechanism to achieve this task ( in case it is feasible )...


Yes, you could do that.

I would, however, suggest that you not store pointers in the shared memory.
That's because unless those pointers reference locations in the shared
memory, they are invalid outside of the process that "created" them. In
other words, you can only share references to what is truly shared. :-) So,
if you find a need to share pointers you would store offsets from the start
of the shared memory instead. In that way, each of the processes mapping the
memory could map at any convenient address.

Regards,
Will
Nov 17 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Steve Guidos | last post: by
5 posts views Thread by Michael | last post: by
3 posts views Thread by Jim Langston | last post: by
32 posts views Thread by moleskyca1 | last post: by
3 posts views Thread by Newish | last post: by
reply views Thread by =?Utf-8?B?Zmplcm9uaW1v?= | last post: by
reply views Thread by NPC403 | last post: by
1 post views Thread by UniDue | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.