Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1032
  • Last Modified:

#pragma data_seg("shared") and threads?

In 16-bit land data in a dll could be shared. In 32-bit land the data can still be shared but must be declared in a #pragma data_seg compiler directive.

If I do this is there a new problem of the data being accessed across different thread boundaries? In which case do I have to place a critical section around access to all the shared data?
0
sdj_work
Asked:
sdj_work
  • 2
1 Solution
 
piano_boxerCommented:
As with any static variable(s) in your code, you have to protect it if it is accessed from multiple threads at the same time, and one or more threads of them are modifying the variable(s).

In your case you also have to use a named mutex (or simular) that can be accessed from all the processes the uses the DLL.

There is one problem with shared data segment in DLL. When another process loads the DLL and Windows loads it at another address because of a conflict with a another DLL, it will *not* get the same shared data as the other processes using your DLL. You can almost solve the problem by specifying the load address for the DLL, but your will not be 100% sure.

I suggest that you use memory mapped files ( without the file ) protected by a named mutex.

Here is how to initialize the mutex and shared memory mapped file:

...............

// Your own data structure goes here!
struct MY_DATA_STRUCT
{
    DWORD dwSomeValue;
    char  szSomeText[1024];
};

//
// Unique names of objects
//
LPCTSTR pszMutexName = "MyApp_Mutex";
LPCTSTR pszMapName = "MyApp_MemMap";

//
// Open the mutex and lock it.
//
BOOL bNew = TRUE;
HANDLE hMutex = CreateMutex(NULL, TRUE, pszMutexName);
if(GetLastError() == ERROR_ALREADY_EXISTS)
    bNew = FALSE;

//
// Create the memory mapped file for holding the
// MY_DATA_STRUCT structure.
//
HANDLE hFileMap = CreateFileMapping((HANDLE)0xffffffff, NULL,      PAGE_READWRITE | SEC_COMMIT, 0, sizeof(MY_DATA_STRUCT),pszMapName);

MY_DATA_STRUCT* pMyData = (MY_DATA_STRUCT*)MapViewOfFile(hFileMap, FILE_MAP_ALL_ACCESS, 0, 0, 0);

//
// Zero out the memory if it did not exists all-ready.
//
if(bNew)
    ZeroMemory(pMyData, sizeof(MY_DAtA_STRUCT));

//
// Release lock on shared memory
//
ReleaseMutex(hMutex);

////////////////////////////////////////////
// ACCESSING DATA
////////////////////////////////////////////

// Gain exclusive access to the data
WaitForSingleObject(hMutex, INFINITE);

// Modify/read data frim the structure now.
pMyData->dwSomeValue += GetTickCount();

// Release the lock on the memory.
ReleaseMutex(hMutex);


////////////////////////////////////////////
// CLEANUP CODE:
////////////////////////////////////////////
UnmapViewOfFile(pMyData);
CloseHandle(hFileMap);
CloseHandle(hMutex);
0
 
sdj_workAuthor Commented:
Is this point about the DLL process not getting the same shared area not covered by KB article: Q100634. In which case pointers would not actually work correctly but the data *is* still shared correctly?

Otherwise there would be no point in implementing the feature.
0
 
piano_boxerCommented:
This is from Q100634:

"if the block cannot be loaded into the same memory address, it is mapped to a different address, but it is still shared.".

So I guess I'm wrong about data not beeing shared when dll's are relocated, but I would still use the memmory mapped file method.
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now