Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / Managed C++ / May 2004

Tip: Looking for answers? Try searching our database.

SharedMemory Base address mapping

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Nadav - 03 May 2004 23:46 GMT
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.
William DePalo [MVP VC++] - 04 May 2004 01:10 GMT
> 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
Nadav - 04 May 2004 08:56 GMT
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
William DePalo [MVP VC++] - 04 May 2004 18:25 GMT
> 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
[quoted text clipped - 7 lines]
> ( 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

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.