[win32/c++] Shared memory met pointers

[Verwijderd]

Ik heb een programma waar ik een stuk geheugen share:

C++:

typedef struct teststruct {
  int a, b;
} TESTSTRUCT_DES;
TESTSTRUCT_DES TESTSTRUCT;
TESTSTRUCT_DES *Memory;

HANDLE hFile = CreateFile ("c:\\test.txt", GENERIC_READ | GENERIC_WRITE, FILE_SHARE_READ, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
hMemory = CreateFileMapping (hFile, NULL, PAGE_READWRITE, 0, 10*sizeof(int), "KILNLOGMEM");
Memory  = (TESTSTRUCT_DES*)MapViewOfFile (hMemory, FILE_MAP_WRITE, 0, 0, sizeof(TESTSTRUCT_DES));

TESTSTRUCT.a=1;
TESTSTRUCT.b=2;
Memory = &TESTSTRUCT;

En in een ander programma lees ik deze waarden als volgt weer uit:

C++:

hMemory = OpenFileMapping(FILE_MAP_READ, 0, "KILNLOGMEM");
Memory  = (TESTSTRUCT_DES*) MapViewOfFile(hMemory, FILE_MAP_READ, 0, 0, sizeof(TESTSTRUCT_DES));

Nou werkt dit helemaal goed, tenzij ik in de struct een pointer plaats, zoals bijvoorbeeld int* c, dan kunnen geen van de waarden gelezen worden (a en b staan op 0 en bij c staat Error, expression cannot be evaluated.

Ik compileer alles op dezelfde computer onder hetzelfde os. Wel gebruik ik twee verschillende compilers, maar dit zou voor de omvang van int's en pointers naar int's toch niets uit moeten maken? En als ik een pointer naar een array van chars stuur, of een enkele pointer naar een int werkt het wel. Alleen pointers binnen de struct werken niet. Iemand enig idee?

[ Voor 6% gewijzigd door Verwijderd op 20-06-2003 03:35 ]

[.oisyn]

Je kunt niet met pointers werken met memory-mapped files of shared memory, omdat het adres van het stuk geheugen in beide processen anders kan zijn

De oplossing is om in plaats van pointers te werken met integers die de offset in het shared memory aangeven

[curry684]

Of je gebruikt geen filebased MemoryMapped files (ja dat kan, zie de docs) dan is het geheugen wel in beide processen hetzelfde.

[.oisyn]

curry684 schreef op 20 June 2003 @ 12:20:
Of je gebruikt geen filebased MemoryMapped files (ja dat kan, zie de docs) dan is het geheugen wel in beide processen hetzelfde.

ook bij shared memory kan het blok toch in beide processen op een verschillend base address beginnen?

[klinz]

[b]Verwijderd schreef op 20 June 2003 @ 03:31Ik compileer alles op dezelfde computer onder hetzelfde os. Wel gebruik ik twee verschillende compilers, maar dit zou voor de omvang van int's en pointers naar int's toch niets uit moeten maken? En als ik een pointer naar een array van chars stuur, of een enkele pointer naar een int werkt het wel. Alleen pointers binnen de struct werken niet. Iemand enig idee?

Waarom geef je hFile aan CreateFileMapping mee? Met CreateFileMapping($ffffffff, ...) gaat het beter (lees wat de win32 sdk te zeggen heeft over die $ffffffff). Je hoeft dan ook geen CreateFile aan te roepen. Je wilt immers memory sharen, geen file :-)

.oisyn schreef op 20 June 2003 @ 13:03:
[...]
ook bij shared memory kan het blok toch in beide processen op een verschillend base address beginnen?

Het zou me niets verbazen. Een kleine empirische test (onder win98 weliswaar, win2k gaat er waarschijnlijk anders mee om) zegt me echter dat het adres steeds hetzelfde is (ergens boven de 2GB).

[ Voor 25% gewijzigd door klinz op 23-06-2003 23:31 . Reden: Verkeerd gelezen ]

[curry684]

.oisyn schreef op 20 June 2003 @ 13:03:
ook bij shared memory kan het blok toch in beide processen op een verschillend base address beginnen?

Windows werkt altijd met absolute far pointers dus lijkt me sterk op z'n zachtst gezegd Je gebruikt fysiek hetzelfde blok geheugen waarbij de MMU van de CPU simpelweg access aan allebei de processen verleent. Lijkt me eigenlijk juist pas mogelijk op het moment dat je shared files gebruikt, die kunnen op andere adressen gemapped worden.

[klinz]

curry684 schreef op 23 June 2003 @ 23:32:
[...]

Windows werkt altijd met absolute far pointers dus lijkt me sterk op z'n zachtst gezegd Je gebruikt fysiek hetzelfde blok geheugen waarbij de MMU van de CPU simpelweg access aan allebei de processen verleent. Lijkt me eigenlijk juist pas mogelijk op het moment dat je shared files gebruikt, die kunnen op andere adressen gemapped worden.

Het is inderdaad fysiek hetzelfde geheugen (of swap), het wordt echter wel (onder win98 tenminste) boven de 2GB gemapped.

[curry684]

Lijkt me stomtoevallig omdat je gewoon een stuk geheugen gebruikt. Heb je al eens gechecked waar al jouw geheugen wordt gemapped? Misschien heb je wel altijd een DIMMetje op adres 0x80000000 zitten....

[klinz]

Niet helemaal toevallig:



Uit:
http://msdn.microsoft.com/msdnmag/issues/0700/Hood/default.aspx

[curry684]

Zo leer je zelfs als Windowshippie nog eens wat

[.oisyn]

curry684 schreef op 23 June 2003 @ 23:32:
[...]

Windows werkt altijd met absolute far pointers dus lijkt me sterk op z'n zachtst gezegd Je gebruikt fysiek hetzelfde blok geheugen waarbij de MMU van de CPU simpelweg access aan allebei de processen verleent. Lijkt me eigenlijk juist pas mogelijk op het moment dat je shared files gebruikt, die kunnen op andere adressen gemapped worden.

hoewel het fysiek hetzelfde blok geheugen is hoeft het ivm paging niet op hetzelfde virtuele adres te staan. En aangezien ik dacht dat shared memory in het proces' addresspace werd gemapped kon het dus zo zijn dat hetzelfde stuk geheugen uiteindelijk op 2 verschillende adressen gemapped werd in 2 verschillende processen. Maar dat is dus niet zo

.edit: en tadaaa:

To share dynamically allocated memory between processes, all programs wanting to see the memory must use memory mapped files. In Windows NT®, there's no guarantee that two processes will even see the shared memory at the same address. For Windows 9x, the story is more convoluted—basically, the entire region between 2GB and 3GB is accessible to all programs (although you're not supposed to rely on this fact in your programming).

ik wist dat ik het ergens gelezen had
(uit hetzelfde document dat klinz aanhaalde)

[ Voor 26% gewijzigd door .oisyn op 24-06-2003 11:21 ]