[C++] Threadsafe programmeer probleem

[TheGhostInc]

Ik zit met de volgende vraag, en ik heb na een MSDN/Internet zoektocht nog niet gevonden. Mocht dit toch duidelijk in de MSDN of ergens anders staan, excuses ik heb het nog niet gevonden.

In het systeem zijn op dit moment 2 objecten aanwezig die allebei een thread bevatten. Deze 2 objecten passen een model aan dat bestaat uit een collectie objecten.
Beide threads zijn instaat om objecten aan te maken dan wel te verwijderen uit het model, maar kunnen ook data lezen uit het model

Beide threads zijn totaal verschillend en kennen elkaar niet, ze moeten dus beschermd worden tegen elkaar, zodat een object niet verwijderd kan worden terwijl een ander er net van wil lezen.

Het liefst wil ik een hele set objecten in een keer kunnen locken ipv. per object.
Op welke manier kan ik het systeem het beste threadsafe maken?

[TheGhostInc]

Een optie zou zijn om bijvoorbeeld een globale semafoor/mutex aan te maken, en beide threads deze te laten gebruiken, maar dat betekent dat als de thread deze semafoor door een code fout niet gebruikt het systeem hard op zijn gezicht kan gaan.
(Waarbij ik waarschijnlijk lang aan het zoeken ben om de fout te vinden)

Is er een mechanisme wat mij hierbij kan helpen?

[Zoijar]

TheGhostInc schreef op 31 maart 2004 @ 16:41:
Een optie zou zijn om bijvoorbeeld een globale semafoor/mutex aan te maken, en beide threads deze te laten gebruiken, maar dat betekent dat als de thread deze semafoor door een code fout niet gebruikt het systeem hard op zijn gezicht kan gaan.
(Waarbij ik waarschijnlijk lang aan het zoeken ben om de fout te vinden)

Is er een mechanisme wat mij hierbij kan helpen?

Je plaatst de semaphore ook niet in de code van beide threads, maar op de shared buffer. Het makkelijkste is om een 'monitor' constructie te maken; dwz je threads hebben alleen een soort van smart-pointer naar de buffer/model, en bij elke pointer dereference (operator->) wordt er een semafoor geupped, de methode aangeroepen, en dan weer gedowned. (er staat me een artikel van stroustroup bij, dat een elegante template monitor class beschrijft...)

Oh in windows heb je als basis mutex ondersteuning 'CRITICAL_SECTION' en de functie EnterCriticalSection en LeaveCriticalSection. MFC heeft dacht ik echte semaphore classes, maar die zou je ook zelf kunnen maken. Een ander nuttig begrip is 'double checked locking pattern', als je besluit een controlled singleton te gebruiken.

[ Voor 25% gewijzigd door Zoijar op 31-03-2004 18:35 ]

[.oisyn]

Zoijar schreef op 31 maart 2004 @ 18:29:
Oh in windows heb je als basis mutex ondersteuning 'CRITICAL_SECTION' en de functie EnterCriticalSection en LeaveCriticalSection. MFC heeft dacht ik echte semaphore classes, maar die zou je ook zelf kunnen maken.

Bedoel je daarmee dat win32 dat niet native ondersteunt, of dat het dan gewoon niet in OO vorm is?
Want win32 ondersteunt het natuurlijk wel, met CreateSemaphore () maak je er een aan, en met ReleaseSemaphore en de wait functies verhoog je resp. verlaag je de count

(Ik denk overigens dat jij dat ook wel weet Zoijar, maar zoals het er nu staat lijkt het een beetje over te komen alsof de win32 api het niet native ondersteunt )

[ Voor 13% gewijzigd door .oisyn op 31-03-2004 20:38 ]

[Zoijar]

.oisyn schreef op 31 maart 2004 @ 20:31:
Bedoel je daarmee dat win32 dat niet native ondersteunt, of dat het dan gewoon niet in OO vorm is?
Want win32 ondersteunt het natuurlijk wel, met CreateSemaphore () maak je er een aan, en met ReleaseSemaphore en de wait functies verhoog je resp. verlaag je de count

Oh, ja ik ben niet zo heel erg thuis in win32 Maakte die dingen altijd zelf...hoewel, eigenlijk gebruik ik altijd blocking message passing.

.oisyn schreef op 31 maart 2004 @ 20:31:
(Ik denk overigens dat jij dat ook wel weet Zoijar, maar zoals het er nu staat lijkt het een beetje over te komen alsof de win32 api het niet native ondersteunt )

Ik ben blij dat ik zo hoog wordt ingeschat hehehe

[ Voor 24% gewijzigd door Zoijar op 31-03-2004 20:44 ]

[Verwijderd]

Kun je niet de objecten relationeel maken, en dan dmv een tree structuur een set objecten locken. Lock een object en zijn childs worden vervolgens ook onderdeel van de lock.

[.oisyn]

Zoijar schreef op 31 maart 2004 @ 20:41:
Ik ben blij dat ik zo hoog wordt ingeschat hehehe

hmm ok mijn fout

[TheGhostInc]

Zoijar schreef op 31 maart 2004 @ 18:29:
[...]

Je plaatst de semaphore ook niet in de code van beide threads, maar op de shared buffer. Het makkelijkste is om een 'monitor' constructie te maken; dwz je threads hebben alleen een soort van smart-pointer naar de buffer/model, en bij elke pointer dereference (operator->) wordt er een semafoor geupped, de methode aangeroepen, en dan weer gedowned. (er staat me een artikel van stroustroup bij, dat een elegante template monitor class beschrijft...)
[...]

Ok, dit is inderdaad wat ik zocht, een elegante manier om het te doen.
Nu is alleen mijn vraag, hoe doe ik dit in de praktijk.

Kan iemand mij een linkje of pseudo code geven die dit iets verder beschrijft.

Echter ik zit er even over na te denken, als ik echter via een object in het model een ander object in het model wil aanspreken, zal dat dan in deze trant moeten:

object1->object2->object3->woei();

Want de oplossing met:

temp2 = object1->object2
temp3 = temp2->object3
temp3->woei();
Loop ik risico dat er een object tussentijds verdwijnt.

Of moet de semafoor dan gelocked worden in het object3 tijdens de uitvoer van de functie woei()?

Want object2 zou in dit geval al pleitte kunnen zijn nadat je de pointer naar dit object hebt gevraagd, aangezien het model dan nog niet gelocked is.

[curry684]

Maak gewoon van de container zelf een 'guarded queue', oftewel een container class die in z'n Add(), Remove() etc. functies een mutex bijhoudt. Risico dat een fetched object verdwijnt vlak na lookup blijf je behouden tenzij je een smart pointer of andere reference counting constructie bouwt, of je moet gewoon een static mutex in de 'manager' classes maken die alle gebruik van de queue of zijn objecten serializeert.