Multithread osztott erőforrás

Multithread osztott erőforrás
2012-03-09T10:15:12+01:00
2012-03-09T12:00:33+01:00
2022-11-24T23:40:41+01:00
*deleted_77141665
Sziasztok!

Végigböngésztem az oldalt thread, multithread és osztott memória szavakat tartalmazó témák után, lehet, hogy egyértelmű a dolog és azért, de nem találtam semmit. Két elméleti kérdésem lenne.

Fejlesztek egy szoftvert, ami több szálat indítana (legyenek pl:. t1, t2, t3), és mindegyik szál ugyanazt a memória területet olvasná és írná. Az msdn.com-on írják a kölcsönös kizárás elvét, a közös erőforrás védelmére:

HANDLE hIOMutex= CreateMutex (NULL, FALSE, NULL); WaitForSingleObject( hIOMutex, INFINITE ); fseek( fp, desired_position, 0L ); fwrite( data, sizeof( data ), 1, fp ); ReleaseMutex( hIOMutex);

Én úgy gondolom, hogy ez jó nekem, mert ugye mindegyik szál addig vár, amig a hIOmutex nem jelez, és az addig nem jelez, amíg egy szál (t1) a közös erőforrást bizergálja. Ha pedig egyszerre két szál (t2 és t3) várakozik a hIOmutex jelzésére, akkor a processzor úgyis egyidőben csak az egyik szálat (t2) fogja elindítani, és az a magáévá teszi az erőforrást így amikor a proci a másik szálat (t3) futtatja, az már foglaltnak látja az erőforrást. A kérdésem az lenne, hogy jól gondolom?

A másik kérdésem pedig, hogy mi van a többmagos procikkal? Akkor is működik a dolog automtikusan, vagy kell hozzá valamilyen sámántánc? Konkrétan erre az esetre a volatile kulcsszóval deklarált handle-ra gondoltam, mert minden írás olvasás előtt a memóriához fordul a program és nem fordulhat elő, hogy a regiszterben lévő érték miatt az egyik mag hibázik. Szerintem.

Köszönöm a segítséget előre is.
Mutasd a teljes hozzászólást!
A mutexet egyszerre csak egyvalaki birtokolhatja, ezt az oprendszer intézi neked, nem kell miatta aggódni. És igen, természetesen az ütemező lekezeli több mag esetén is a dolgot.

A volatile kulcsszó nem tudom, hogy szükséges-e a közösen használt memóriára. Elvileg a fordítónak nem illene regiszterben tartania azt, amit egy másik függvény esetleg már olvasna is ki memóriából. A processzor cache-ek szinkronizálását szerintem elintézi a kernelhíváskor történő kontextusváltás, de erre azért nem veszek mérget. Ártani biztos nem fog a volatile.

A handle-re viszont felesleges a volatile kulcsszó, mivel a handle értéke még csak nem is változik futás közben, csak az ő általa reprezentált, kerneloldali adatszerkezet.

A másik dolog, hogy ha egy processzen belül kell csak a szinkronizáció, akkor mutex helyett használhatsz olcsóbb critical section-t. Ugyanazt tudja, de azzal a megszorítással, hogy csak a közös memórián osztozó kódok tudják használni, vagyis egy processzen belül a szálak.
Mutasd a teljes hozzászólást!

Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd