Archived

This topic is now archived and is closed to further replies.

Ranger_One

Dlls & Memory? (I dun get it)

Recommended Posts

OK I just started using DLLs for applications and here is my question. I setup some global data in the DLL, it''s a table of class pointers. Each pointer can hold a class IVariable. The first time that the DLL is loaded, the global table is initialized. Now I have DLL functions to Create and Query IVariables by their "name" (a 24 char string in this case). Here I go: If I have two processes load up the DLL, they will be using the same global table. If one process query a variable Created by the other, what will happen? Windows says something to the extent that DLL memory cannot be shared, so in that case the pointer returned from the DLL function will be invalid? If this is the case I dun get it. Thanks, R1

Share this post


Link to post
Share on other sites

quote:
If I have two processes load up the DLL, they will be using the same global table.


Wrong assumption!. Address space of a DLL is "Copy on Write", which means each time a new process writes to a global variable in the DLL, a ***COPY*** is made of that variable specific to that process.

The best way round that is to make a shared section in the DLL and force the shared variable into that section.

An example of a shared section (somewhere in a source file):


#pragma data_seg( "ASYLUM" )

volatile int g_iInstanceCount = 0;
volatile bool g_bSomeOtherSharedValue = false;

#pragma comment( linker, "/SECTION:ASYLUM,RWS" )

#pragma data_seg()


The data_seg pragmas create a new section called "ASYLUM" to contain the data in between.

The comment pragma sends some extra options to the linker to make the ASYLUM section [R]eadable, [W]ritable and importantly [S]hared.

The variables must be initialised globally so they don''t end up in a BSS section.

The volatile prevents the compiler from trying to optimise code using those variables (it could move them into a different section or not know than another process will modify them etc)

--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com

Share this post


Link to post
Share on other sites