[win32/alg] mutual read/write exclusion op veel objecten

[.oisyn]

Situatie
We zijn bezig met een online spel met een persistente wereld, en waar heel veel users tegelijk samen met elkaar kunnen spelen. Nou is er aan de serverkant behoorlijk wat data, en aangezien het multithreaded is moet het zaakje wel thread-safe zijn. Hierbij moet je denken aan zo'n 10.000 (ruwe schatting) objecten waar read-locks en write-locks op gedaan kunnen worden.

Op een object kunnen door meerdere threads read-locks gedaan worden zonder dat ze in de wachtrij komen te staan (data lezen is immers niet aanpassen, dus is er ook geen gevaar). Er mag echter maar 1 write-lock op een object gedaan zijn, en als er een write-lock is mag er niet gelezen worden. Ook mag er natuurlijk geen write-lock worden gedaan als er threads al aan het lezen zijn

Probleem
10.000 is behoorlijk wat, en 10.000 Mutexen aanmaken zal Windows niet echt fijn vinden. Een CRITICAL_SECTION zou iig beter zijn... Maar hoe pak ik het beste aan dat een read-lock niet op een read-lock wacht, maar wel op een write-lock, en een write-lock altijd wacht op elk soort lock? Wat voor synchronisatie-object kan ik hiervoor gebruiken?


Hmmm nu ik dit schrijf bedenk ik me iets... ik kan natuurlijk ook gewoon alle game-logic af laten handelen door 1 thread, en de communicatiethreads queue'en gewoon de commando's die binnenkomen van de users. Dan hoef ik niet eens gebruik te maken van mutual exclusion, aangezien er altijd maar 1 thread is die ermee bezig is. Maar goed, die optie laat ik even open, misschien komen hier nog wat leuke ideetjes voorbij

[Soultaker]

Ik denk dat de optie die je noemt, misschien wel erg geschikt is. Je kunt je afvragen of het nuttig is om een multithreaded implementatie te bouwen, als die threads in de praktijk zo vaak met dezelfde data werken, dat het aantal threads dat tegelijk kan draaien, beperkt blijft. In dat geval is het waarschijnlijk eenvoudiger (en efficienter, vanwege het ontbreken van de overhead van de synchronisatiemechanismen) om zoveel mogelijk aspecten in een enkele thread te laten plaatsvinden.

Daarbij zou het goed kunnen dat in veel gevallen de communicatie de bottleneck is en niet de verwerking van de commando's, maar dat hangt natuurlijk van de ingewikkeldheid daarvan af. Het nut van twee aparte threads gebruiken, als in de praktijk de communicatiethread 90% van de tijd in een select call vast zit, is natuurlijk ook niet groot. Dan kun je je beter de synchronisatieoverhead besparen en alles in een enkele thread afhandelen.

Heb je trouwens uitgeprobeerd of Windows 10.000 mutexen aan kan maken? Op zich lijkt me dat niet zo'n probleem; in 't geheugen moet 't wel passen (al weet ik niet zeker over Windows een limiet stelt aan het aantal mutexen dat uitgegeven kan worden).

Ik geloof trouwens dat Windows uit zichzelf alleen de mutex en de semafoor ondersteund. Als je een read-write lock wilt hebben, zul je deze dus zelf moeten implementeren, of gebruik moeten maken van een POSIX thread library voor Windows.

Disclaimer: ik heb geen uitgebreide ervaring met de ontwikkeling van high-performance multithreaded systemen, dus misschien denk ik hier te makkelijk over.

[MSalters]

Windwos mutexen zijn cross-process, i.t.t. Critical sections. Als je spel een enkele app is, dan hoef je dus niet de flexibiliteit van mutexen te hebben. Critical sections zijn efficienter in die situatie.
Wat verstandig is hangt erg sterk af van de verhouding read/writes op de data, en het gemiddeld aantal read-locks op een gelockt object. Als 95% van de read-locks enkelvoudig zijn, dan hoef je niet te optimaliseren voor de tweede thread.
Overigens denk ik dat het het handigst is om een atomaire access-control flag te gebruiken, Die flag bevat dan b.v. waarden 0 (vrij), 1..N ( aantal read locks ) of -1 (write lock). Read/Write access van deze flag kan dan via atomaire operaties, of eventueel een critical section. Het voordeel van atomaire operaties is dat ze nog sneller dan critical sections zijn.

[farlane]

MSalters schreef op 10 oktober 2002 @ 08:13:
Overigens denk ik dat het het handigst is om een atomaire access-control flag te gebruiken, Die flag bevat dan b.v. waarden 0 (vrij), 1..N ( aantal read locks ) of -1 (write lock). Read/Write access van deze flag kan dan via atomaire operaties, of eventueel een critical section. Het voordeel van atomaire operaties is dat ze nog sneller dan critical sections zijn.

Zou je kunnen uitleggen wat atomaire operaties zijn ?

[johnwoo]

farlane schreef op 10 oktober 2002 @ 09:05:
[...]


Zou je kunnen uitleggen wat atomaire operaties zijn ?

Atomaire operaties worden als geheel uitgevoerd, zonder dat een andere thread stiekum halverwege tussendoor om de hoek komt kijken. Soort synchronized zegmaar.

[whoami]

johnwoo schreef op 10 oktober 2002 @ 09:21:
[...]

Atomaire operaties worden als geheel uitgevoerd, zonder dat een andere thread stiekum halverwege tussendoor om de hoek komt kijken. Soort synchronized zegmaar.

Ik dacht eerder dat atomair eerder iets wou zeggen in de trant van 'alles of niets'. Of wel worden alle operaties uitgevoerd, ofwel wordt er geen enkele operatie uitgevoerd.
Maar goed, we gaan hier wel redelijk off-topic en ik ga me hier verder buitenhouden uit deze thread. (qua reacties dan toch).

[D2k]

whoami schreef op 10 oktober 2002 @ 10:17:
[nohtml]
[...]
[/nohtml]

Ik dacht eerder dat atomair eerder iets wou zeggen in de trant van 'alles of niets'. Of wel worden alle operaties uitgevoerd, ofwel wordt er geen enkele operatie uitgevoerd.
Maar goed, we gaan hier wel redelijk off-topic en ik ga me hier verder buitenhouden uit deze thread. (qua reacties dan toch).

atomair betekend ondeelbaar dus het kan niet onderbroken worden, en jouw alles of niets is wat vaag
/offtopic

[curry684]

johnwoo schreef op 10 oktober 2002 @ 09:21:
Atomaire operaties worden als geheel uitgevoerd, zonder dat een andere thread stiekum halverwege tussendoor om de hoek komt kijken. Soort synchronized zegmaar.

Je bedoelt serialized: de operaties worden per definitie netjes na elkaar uitgevoerd.

Zie voor voorbeelden van atomaire operaties in Win32 de functie InterlockedExchangeAdd en aanverwante familie.

_{ps. Oisyn ik heb je mails dus ontvangen, later meer reactie ben nu 'even' hard aan het werk}

[curry684]

Quick reply: ik heb in MUD-programming gezeten, je weet wel van die text-based multiplayer games in persistente werelden , en als je iets van die strekking aan het doen bent kun je die 10000 vergeten, maak er maar snel minstens het tienvoudige van voor een beetje leuke 50-simultaneous player mud.

Ik betwijfel overigens of het slim is om truly parallel te gaan: wat ik deed in een mud was het compleet async multithreaded afhandelen van de connecties, en daarin de commando's parsen naar executable command-classes. De uiteindelijke command-class gaat dan vervolgens in een guarded queue, alwaar de centrale processingthread alle commando's serialized op FIFO-basis afhandelt. Dit maakt iedere vorm van synchronizatie op de afzonderlijke objecten overbodig (behalve wellicht de Player-class, afhankelijk van je aanpak, maar dat zijn er nooit 10000).

[DOH!]
Zie net dat je deze oplossing hier ook al als laatste alinea had getikt, had je dat niet mee kunnen mailen

Iig. is dat voor imho voor de meeste games idd de beste oplossing dus

[ Voor 0% gewijzigd door curry684 op 10-10-2002 13:31 . Reden: DOH!!!! ]

[curry684]

ps. de klassieke mud engines met tienduizenden kamers, tienduizenden items, duizenden mob's en tientallen tot honderden spelers zijn allemaal single-threaded processes... heeft ook zo z'n voordelen fyi.

[.oisyn]

allereerst bedankt voor alle reacties. Ik ga denk ik idd gewoon voor de single-thread methode

[nohtml]

curry684 schreef op 10 oktober 2002 @ 13:29:
Quick reply: ik heb in MUD-programming gezeten, je weet wel van die text-based multiplayer games in persistente werelden , en als je iets van die strekking aan het doen bent kun je die 10000 vergeten, maak er maar snel minstens het tienvoudige van voor een beetje leuke 50-simultaneous player mud.

Er zijn idd veel meer objecten dan op dat moment in het geheugen staan, maar daarvoor gebruiken we een caching systeem dat is verbonden met een database

Ik heb nu even geen tijd, maar ik zal zo nog posten wat het voor spel is

[.oisyn]

Ok, een korte beschrijving van het spel: het is een MMORPG

En nu een wat langere beschrijving
Het is een ruimtespel, waarbij je de rol van een piloot of commander 'invult'. Je begeeft je in een oneindig grote ruimte, en daar kun je met je schip rond vliegen, handelen, kolonies opstarten op planeten, oorlog voeren, enz.. Kolonies kun je uitbouwen met allerlei gebouwtjes (mining facilities, factories, enz.), en daarmee kun je bijvoorbeeld stoffen delven, producten fabriceren en schepen bouwen. In principe ben je vrij in wat je doet

Er vliegen ook NPC's rond, zoals bijvoorbeeld ruimtepolitie van een bepaalde government die je schepen kunnen doorzoeken op illegale goederen (bijv. slaven en narcotica) als je je in hun territorium bevindt, en piraten die je proberen te overvallen.

Het aantal spelers wordt (ruw) geschat op 1000

Het spel heeft niet echt specifiek een doel, maar natuurlijk wel een persoonlijk doel voor iedere speler, en dat zal algemeen zijn om de grootste te worden, met de meeste schepen en het meeste geld

De client is in principe een 'thin client', maar wel met mooie 3d graphics en geluid

[farlane]

Lijkt een beetje op een cool ( oud ) spel dat ik heb, Privateer. Alleen dat was niet MMO.

Ik ben benieuwd

[Verwijderd]

een critical section in win32 is toch een atomaire operatie? Dat is nou juist waar die critical section voor bedoeld is : er worden tijdens het uitvoeren van die critical section geen taskswitches gedaan.
Is daarmee dus ook iets heel anders dan een mutex, die voor interproces resource locking bedoeld is.

[.oisyn]

Verwijderd schreef op 10 oktober 2002 @ 20:26:
een critical section in win32 is toch een atomaire operatie? Dat is nou juist waar die critical section voor bedoeld is : er worden tijdens het uitvoeren van die critical section geen taskswitches gedaan.
Is daarmee dus ook iets heel anders dan een mutex, die voor interproces resource locking bedoeld is.

nee, in critical sections kan er gewoon van thread geswitched worden
Het zorgt dan ook gewoon een mutual exclusion, alleen kwa performance is het iets beter (en het is lokaal voor een proces)

[curry684]

Verwijderd schreef op 10 oktober 2002 @ 20:26:
een critical section in win32 is toch een atomaire operatie? Dat is nou juist waar die critical section voor bedoeld is : er worden tijdens het uitvoeren van die critical section geen taskswitches gedaan.
Is daarmee dus ook iets heel anders dan een mutex, die voor interproces resource locking bedoeld is.

Een critical section is een mutex die zich niet in de NT-global-namespace bevindt en dus niet door andere processen gebruikt kan worden. Doordat er hierdoor echter geen kernelwerk aan te pas komt is het enkele keren sneller om te claimen/releasen dan een echte mutex.

Lightweight process-local mutex is de volledig dekkende term voor een critical section.

[Soultaker]

curry684 schreef op 10 oktober 2002 @ 13:29:
Ik betwijfel overigens of het slim is om truly parallel te gaan: wat ik deed in een mud was het compleet async multithreaded afhandelen van de connecties, en daarin de commando's parsen naar executable command-classes. De uiteindelijke command-class gaat dan vervolgens in een guarded queue, alwaar de centrale processingthread alle commando's serialized op FIFO-basis afhandelt.

Als ik je goed begrijp, kun je altijd maar het commando van maximaal 1 client afhandelen. Waarom handel je de connecties dan 'compleet async multithreaded' af? Je kunt dan toch gewoon een single-threaded applicatie schrijven, die in een eindeloze lus commando's inleest en uitvoert? Dan hoef je helemaal niets te synchroniseren.

Volgens mij is jou oplossing daar dan ook volledig equivalent mee. Dat je al eerder het commando van een client uit de socket leest, maakt niets uit, als je toch pas een antwoord kan sturen als de commando's van alle andere clients afgehandeld zijn.

Als je voor een beetje drukke bezetting van een paar duizend spelers ook een paar duizends threads moet spawnen, wordt je niet echt gelukkig. Zeker niet bij een MUD, waarin elke thread 99,9% van de tijd zit te slapen, aangezien de client het grootste deel van de tijd zit te lezen of te typen.

[curry684]

Soultaker schreef op 11 oktober 2002 @ 01:52:
Als ik je goed begrijp, kun je altijd maar het commando van maximaal 1 client afhandelen. Waarom handel je de connecties dan 'compleet async multithreaded' af? Je kunt dan toch gewoon een single-threaded applicatie schrijven, die in een eindeloze lus commando's inleest en uitvoert? Dan hoef je helemaal niets te synchroniseren.

Volgens mij is jou oplossing daar dan ook volledig equivalent mee. Dat je al eerder het commando van een client uit de socket leest, maakt niets uit, als je toch pas een antwoord kan sturen als de commando's van alle andere clients afgehandeld zijn.

Vandaar ook dat ik dit in een volgende post toevoegde, met single-threaded is ook niets mis

Enige immediate voordeel is dat je alles async parset en parser errors meteen kunt teruggeven, maar da's redelijk minieme winst. Aan de andere kant geef je meteen je eigen probleem meteen aan: je mag (mocht destijds?) per proces op Linux/BSD maar 255 filedescriptors open hebben, oftewel max. 250 sockets of zo. Als je 10000 spelers wil kunnen hosten moet je dus meerdere client processes spawnen die allemaal.... gesyncronizeerd hun data naar de main process moeten pompen En dan is het handig dat je daarvoor al faciliteiten hebt.

Tevens zijn er slimme manieren om remote 'proxy-servers' op te zetten voor een MUD die connecties afhandelen zodat mensen hun 'most responsive' server kunnen kiezen. De proxies sturen dan de input-data gecomprimeerd door naar de main server over een open TCP-lijn. Dit is een verbazend effectieve manier om lag tegen te gaan feitelijk.

[Verwijderd]

Dat over die atomaire operaties vind ik erg interessant, maar ik kan niks in de MSDN library erover vinden. Daar worden alleen mutexen, semaforen, events en criticalsections genoemd als synchronization objecten. Hoe maak je aan het systeem duidelijk dat je een atomaire operatie uit wil voeren?

[Alarmnummer]

Daar kan je een mutex of een binaire semafoor voor nemen. Als je een kritieke sectie ingaat, doe je een semafoor.down(). Als er al een andere thread bezig is, dan ga je slapen en anders ga je bezig met je kritieke sectie. Als je klaar bent met de kritieke sectie, doe je weer een semafoor.up() en kunnen anderen beginnen aan de kritieke sectie.

En verder is een monitor een hogere orde bouwsteen die je in principe ook op kan bouwen uit lagere orde bouwstenen zoals mutexen en semaforen. Als je in java alle methodes in een object synchronized maakt, dan heb je dus ook een monitor: iedere methode is een atomaire operatie.

[curry684]

Verwijderd schreef op 11 oktober 2002 @ 13:19:
Dat over die atomaire operaties vind ik erg interessant, maar ik kan niks in de MSDN library erover vinden. Daar worden alleen mutexen, semaforen, events en criticalsections genoemd als synchronization objecten. Hoe maak je aan het systeem duidelijk dat je een atomaire operatie uit wil voeren?

Een echt atomaire operatie kun je niet definieren, die bestaat al of niet op CPU niveau: een interrupt en dus thread switch kan enkel tussen CPU instructies plaats vinden, niet tijdens.

Leesvoer in MSDN.

[Verwijderd]

Alarmnummer : de door jouw beschreven methode doet dus niet wat ik wil. Hij prevent namelijk geen taskswitch in het blok code. Wat jij beschrijft is volgens mij een non-criticalsection implementatie van een criticalsection (dus met behulp van mutexen/semaforen i.p.v een critical section). Misschien was ook niet helemaal duidelijk dat ik een C++ win32 oplossing zocht, sorry.

curry : die paar MSDN functies zijn echt alleen maar voor relatief simele arithmic operations, niet om een heel blok code atomic te maken. Kennelijk kan dat niet in C++
In assembly ging dat vroeger toch heel aardig. Met behulp van buslocks en het disablen van interrupts garandeerde je dat een stukje code de volledige beschikking had over de processor. Hoe ik dat in protected mode zou moeten implementeren weet ik niet : ik ben redelijk gestopt met assembly toen real mode verleden tijd was (gewoon geen zin om alles opnieuw te schrijven).

[Alarmnummer]

Verwijderd schreef op 11 oktober 2002 @ 14:53:
Alarmnummer : de door jouw beschreven methode doet dus niet wat ik wil. Hij prevent namelijk geen taskswitch in het blok code.

Ik denk dat windows dat ook niet zo leuk vindt Als een applicatie de mogelijkheid zou hebben, dan zou hij heel windows vast kunnen lopen als het dat na afloop niet weer aanschakelt.

Wat jij beschrijft is volgens mij een non-criticalsection implementatie van een criticalsection (dus met behulp van mutexen/semaforen i.p.v een critical section).

Een critical section is niet anders dan een naam voor een regio code waarvan gegarandeerd moet worden dat de data die aangesproken wordt, maar door 1 proces tegelijk aangesproken kan worden. Dit kan je dus voor elkaar krijgen met lagere bouwstenen zoals een semafoor of een mutex. Of met hogere orde bouwstenen zoals een monitor.

Misschien was ook niet helemaal duidelijk dat ik een C++ win32 oplossing zocht, sorry.

Het uitschakelen van interrupts is not done onder windows

Als er trouwens een taskswitch wordt uitgevoerd terwijl een proces met een kritieke sectie bezig was, dan zullen alle processen die daar ook mee aan de slag willen, niet toegelaten worden. Uiteindelijk komt het proces dat in de kritieke sectie zat weer aan beurt en die mag dus verdergaan met het gene wat hij aan het doen was. Je hoeft dus niet bang te zijn dat er in een kritieke sectie (die is beveiligd) andere threads op hetzelfde moment bezig zijn, ook al is het os aan het taskswitchen.

[Alarmnummer]

Anders moet je even kijken of je 'Modern Operating Systems' van Tanenbaum kan krijgen (is ook wel 2e hands te krijgen). Hierin staat wel wat uitleg hierover. Eigelijk moet iedere it`er dit boek in zijn bezit hebben

[Verwijderd]

Alarmnummer : dat van die critical section snap ik nou wel
Waar het om gaat is dat ik eventueel zou willen lezen uit een file. Nou wil ik niet dat er tijdens een setje lees operaties door een andere thread/proces een schrijfactie naar die file wordt gedaan. Dat zou ik dus kunnen voorkomen door taskswitches/interrupts te 'verbieden' tijdens het blok code wat de leesacties doet. Ik hoor je al denken "open dan gewoon de file in SHARE_DENY_WRITE mode", maar dat moet ik dan wel iedere keer doen dat ik zo'n setje leesacties doe. Dat is dus iedere keer een nieuwe CreateFile aanroep (anders zouden andere processen uberhaupt niet kunnen schrijven). Dat kan dus opzich wel, maar geeft wel weer extra overhead. Misschien dat dat nou niet echt een bron van zorgen zou moeten zijn, maar ik had het toch leuk gevonden als dat niet had gehoeven...

[Verwijderd]

'Modern Operating Systems' van Tanenbaum

ISBN nummer?

[curry684]

Alarmnummer schreef op 11 oktober 2002 heel vaak:
kritieke sectie

Zo'n beest heet een critical section! Of heb je het ook over een weduit als je een mutex bedoelt?

Oh en jullie zitten erg veel langs mekaar te lullen, erg geinig om vanuit de 3e persoon te zien hoe 2 mensen die allebei weten hoe synchronizatie werkt aan mekaar proberen uit te leggen hoe synchronizatie werkt en er vervolgens allebei geen hout meer van snappen

[Alarmnummer]

curry684 schreef op 11 oktober 2002 @ 17:33:
[...]
Zo'n beest heet een critical section!

Aha, en een nederlandse naam is ineens verboden

Oh en jullie zitten erg veel langs mekaar te lullen, erg geinig om vanuit de 3e persoon te zien hoe 2 mensen die allebei weten hoe synchronizatie werkt aan mekaar proberen uit te leggen hoe synchronizatie werkt en er vervolgens allebei geen hout meer van snappen

Ik wou aan hem uitleggen dat een kritieke sectie een stuk code is dat beveiligd moet worden, en dat mutexen,semaforen,monitoren ed manieren zijn om dat voor elkaar te krijgen. Volgens mij had hij dat niet in de gaten.

en ISBN = 90.395.0284.6

[ Voor 0% gewijzigd door Alarmnummer op 11-10-2002 18:57 . Reden: verkeerd begrepen. ]

[curry684]

Alarmnummer schreef op 11 oktober 2002 @ 18:52:
Aha, en een nederlandse naam is ineens verboden

Heej da's vals, stieken het 2e gedeelte van mijn opmerking niet citeren

Ik vind dus dat als je zonodig Engelstalig vakjargon wil vertalen je ook consequent moet zijn en een mutex (MUTual EXclusion) moet vertalen tot weduit (WEDerzijdse UITsluiting), en anders houd je je maar gewoon aan het jargon, dan snapt iedereen tenminste waar je het over hebt

Ik wou aan hem uitleggen dat een kritieke sectie een stuk code is dat beveiligd moet worden, en dat mutexen,semaforen,monitoren ed manieren zijn om dat voor elkaar te krijgen. Volgens mij had hij dat niet in de gaten.

En da's dus niet waar. Code hoeft nooit beveiligd te zijn, alleen de variabelen die in die code gebruikt worden wellicht (alhoewel multithreaded self-modifying code me op zich wel een uitdaging lijkt ). Om gekruiste access tot de potentieel gevaarlijke variabelen te voorkomen lockt een thread eerst een object dat per definitie thread-safe is. Voorbeelden van verschillende implementaties van zo'n object onder een NT kernel zijn de critical section, de mutex en de semaphore. Voor het subtiele verschil tussen de eerste twee citeer ik mezelf een stuk hierboven:

curry684 schreef op 11 oktober 2002 @ 00:45:
[...]

Een critical section is een mutex die zich niet in de NT-global-namespace bevindt en dus niet door andere processen gebruikt kan worden. Doordat er hierdoor echter geen kernelwerk aan te pas komt is het enkele keren sneller om te claimen/releasen dan een echte mutex.

Lightweight process-local mutex is de volledig dekkende term voor een critical section.

[Alarmnummer]

curry684 schreef op 11 oktober 2002 @ 20:02:
Ik vind dus dat als je zonodig Engelstalig vakjargon wil vertalen je ook consequent moet zijn en een mutex (MUTual EXclusion) moet vertalen tot weduit (WEDerzijdse UITsluiting), en anders houd je je maar gewoon aan het jargon, dan snapt iedereen tenminste waar je het over hebt

zeurkous Ik kan me eerlijk gezegd hier niet zo druk om maken.

En da's dus niet waar. Code hoeft nooit beveiligd te zijn, alleen de variabelen die in die code gebruikt worden wellicht

Hmmzz.. niet zo lastig doen zeg Code zijn niet alleen methodes, maar code is ook data. Code is bij mij het geheel En trouwens kan een functie (bij jou dus code) ook data zijn. C en C++ hebben tenslotte hogere orde functies

Voor het subtiele verschil tussen de eerste twee citeer ik mezelf een stuk hierboven:

Hmmzz.. leuk dat je me dit uitlegd, maar heeft dat een bepaalde reden?

En ik ben verder het 'critical section' object nog nooit tegengekomen als concurrency control bouwsteen. In meerdere concurrency boeken die ik heb doorgebladerd, wordt hiermee een bepaald iets bedoelt dat maar door 1 thread tegelijk aangesproken mag worden.

Ons probleem zit hem in het feit dat er onder nt dus een bouwsteen 'critical section' uit is. En ik ken het dus alleen als een begrip van 'gevaarlijke code'

[MSalters]

Verwijderd schreef op 11 oktober 2002 @ 15:21:
Alarmnummer : dat van die critical section snap ik nou wel
Waar het om gaat is dat ik eventueel zou willen lezen uit een file. Nou wil ik niet dat er tijdens een setje lees operaties door een andere thread/proces een schrijfactie naar die file wordt gedaan. Dat zou ik dus kunnen voorkomen door taskswitches/interrupts te 'verbieden' tijdens het blok code wat de leesacties doet.

Ja, en dat is dus waar je in Win32 de CriticalSection voor kan gebruiken. De read/write code claimt het critical section object wat bij die file hoort. Nu kun je wel een thread switch doen naar een andere thread die los staat van die file, maar andere threads die proberen die file aan te spreken worden onmiddelijk suspended op het moment dat ze die Critical Section als tweede proberen te claimen. Zo verbied je alleen dat storende threads runnen, veel handiger.

[curry684]

Alarmnummer schreef op 11 oktober 2002 @ 20:16:
Ons probleem zit hem in het feit dat er onder nt dus een bouwsteen 'critical section' uit is. En ik ken het dus alleen als een begrip van 'gevaarlijke code'

Zit ook wat in als je de semantics ziet, par example:

C++:

class MyMultiThreadedClass
{
public:    // Methods
  MyMultiThreadedClass()
    {
    InitializeCriticalSection(&m_CriticalSection);
    }
  virtual ~MyMultiThreadedClass()
    {
    DeleteCriticalSection(&m_CriticalSection);
    }
  void UnsafeOperation(...)
    {
    EnterCriticalSection(&m_CriticalSection);

    // Perform edit/read operations on contained data

    LeaveCriticalSection(&m_CriticalSection);
    }

private:    // Properties
  CRITICAL_SECTION         m_CriticalSection;
  SomeDataContainer        m_DataContainer;
};

Zoals je ziet 'treedt je wel een critical section binnen'. Maja zolang er Win32 in de topictitel staat is een critical section echt dat ding in de propertieslijst daar en niet de code tussen de Enter en Leave

ps. Oisyn, is je vraag ondertussen al beantwoord

[Verwijderd]

Ja, en dat is dus waar je in Win32 de CriticalSection voor kan gebruiken. De read/write code claimt het critical section object wat bij die file hoort. Nu kun je wel een thread switch doen naar een andere thread die los staat van die file, maar andere threads die proberen die file aan te spreken worden onmiddelijk suspended op het moment dat ze die Critical Section als tweede proberen te claimen. Zo verbied je alleen dat storende threads runnen, veel handiger.

Je hebt gelijk maar... dat bedoelde ik dus niet. Het gaat mij dus om processen/threads die VERSCHILLENDE code gebruiken om DEZELFDE file te accessen. Een criticalsection werkt alleen op HETZELFDE stuk code (daar is ie voor bedoelt, ook al hoeft dat niet per se. Je zou theoretisch twee verschillende stukken code kunnen beveiligen met dezelfde critical section).

Ik zal even een voorbeeldje geven wat ik nou precies bedoel, dan kan daar in ieder geval geen misverstand meer over onstaan...

Ik heb een programma wat iedere minuut een ini file uitleest om te kijken of z'n settings gewijzigd zijn. Omdat ik tijdens het lezen niet wil dat er iets aan de file veranderd wordt, kan ik een critical section gebruiken. Als ik vanuit een andere thread in datzelfde programma dan met datzelfde block code de file wil accessen, dan is er niks aan de hand, de critical section doet zijn werk en er is geen enkel gevaar.

Er is echter geen enkele garantie dat ik niet in de tussentijd notepad opgestart heb om de file te wijzigen en precies tijdens het lezen van de file op "save" klik. En daar helpt geen critical section,mutex,semafoor of event tegen. Een atomaire operatie zou wel kunnen helpen, maar die kan je dus niet definieren... De enige oplossing is dan om, als ik de file in het programma uitlees, deze te openen met SHARE_DENY_WRITE. Dan kan ik hem ook niet met een ander programma van buitenaf wijzigen. De file wel sluiten na het volledig uitlezen uiteraard, anders kan ik hem nooit wijzigen zolang mijn programma draait (en de file al geopend is). Dat kan dus wel zo, maar echt mooi vind ik het ook niet. Maar helaas

edit:
Wat betreft synchronisatie : ik snap best waar dat voor is en hoe het werkt. Ik was alleen abuis wat betreft die critical section, waarvan ik in eerste instantie dus dacht dat het een atomaire operatie definieerde. Wat overigens hetzelfde effect heeft als een critical section, maar dan uitgebreider...

[Alarmnummer]

Verwijderd schreef op 12 oktober 2002 @ 01:22:
[...]


Je hebt gelijk maar... dat bedoelde ik dus niet. Het gaat mij dus om processen/threads die VERSCHILLENDE code gebruiken om DEZELFDE file te accessen.

class FileMonitor{
...File _file;
...Semafoor _fileSemafoor = new Semafoor(1);
...void methode1(){
......_fileSemafoor.down();
......//kritieke sectie 1
......_fileSemafoor.up();
...}

...void methode2(){
......_fileSemafoor.down();
......//kritieke sectie 2
......_fileSemafoor.up();
...}
}
Dit een een voorbeeld van hoe je dus een resource kan 'locken' mbv een binaire semafoor. Je moet een semafoor zien als een vergunning verlener, en een binaire semafoor kun je zien als een vergunning verlener met 1 vergunning.

Als thread1 methode1 aanroept, dan zal hij bij die filesemafoor komen. Hij vraagt een vergunning aan, en krijgt die omdat nog niemand anders die heeft opgehaald, en kan hij gaan beginnen aan kritieke sectie 1

Stel nu dat thread2 methode2 aanroept, dan zal hij ook bij die filesemafoor komen om een vergunning te vragen. Aangezien thread1 die vergunning al heeft, moet hij gaan wachten.

Uiteindelijk is thread1 klaar, en zal die vergunning terug geven (semafoor.up()) En thread2 die wordt weer wakker gemaakt en zal dan de vergunning ophalen en kan hij beginnen aan kritieke sectie 2

Zoals je zit kun je dus mbv concurrency control structuren zoals een semafoor, bepaalde resources gaan locken vanuit verschillende stukken code, en dat ik dus ook precies wat jij wilt.

Verder heb ik kritieke sectie bold gemaakt, omdat bij mij een kritieke sectie nog steeds een stuk code is, dat beveiligd moet worden door een concurrency control mechanisme, zoals een semafoor. Dat dit begrip onder win32 verkeerd gebruikt wordt, vind ik nogal misleidend.

[Verwijderd]

Alarmnummer : nog een keer dan...
Jouw oplossing snap ik zo ook nog wel. Je doet erg veel moeite om uit te leggen hoe concurrency control werkt, maar dat is gewoon overbodig. Dat weet ik wel.
Jouw oplossing werkt, zoals ik in mijn post hierboven ook al opmerkte, alleen als je bij de source code van een programma kan om die aan te passen. En ik heb dus geen toegang tot de sourcecode van bv. notepad. Het probleem zit em dus in het feit dat proprietairy software een file eventueel ook wil accessen, en ik er niet vanuit kan gaan dat die proprietary software daarvoor een mutex gebruikt. (sterker nog, weet ik wel zeker in het geval van bv. notepad).

Maar goed. Ik had zelf de oplossing al gegeven. Ik vind em alleen niet mooi.

edit:
Alarmnummer : weet je zeker dat je mijn hele voorgaande post gelezen had? Daar zeg ik namelijk al dat het om externe applicaties gaat! Beetje zinloos misverstand dus...

[curry684]

Verwijderd schreef op 12 oktober 2002 @ 01:22:
Je hebt gelijk maar... dat bedoelde ik dus niet. Het gaat mij dus om processen/threads die VERSCHILLENDE code gebruiken om DEZELFDE file te accessen. Een criticalsection werkt alleen op HETZELFDE stuk code (daar is ie voor bedoelt, ook al hoeft dat niet per se. Je zou theoretisch twee verschillende stukken code kunnen beveiligen met dezelfde critical section).

Voor zover ik multithreaded code heb geschreven tot nu toe (en da's toch wel tientallen Mb's aan sourcecode... ) betreft het in 95% van de gevallen dezelfde critical section die door twee of meerdere verschillende stukken code wordt gebruikt. Sterker nog, meestal is het onzinnig om per method een andere critical section te definieren omdat je dan niet correct lockt.

Volgens mij snap je het perfect, maar ben je niet zo'n held met het beschrijven ervan Nuff said dan ook, let's continue on-topic.

[Verwijderd]

curry : dat hangt natuurlijk van je ontwerp af. Het GINA component wat ik mag beheren zit nou eenmaal zo in elkaar dat 'ie die critical sections maar voor 1 blok code gebruikt (het zijn er maar 2 overigens). Verder wel een boel mutexen/events/semaforen, zoals je zou verwachten met dat soort redelijk complexe multithreaded code.
Ook een hell om te debuggen overigens (comp crasht nogal vaak als je GINA iets echt fout doet )

[curry684]

Alarmnummer schreef op 12 oktober 2002 @ 10:46:
Dit een een voorbeeld van hoe je dus een resource kan 'locken' mbv een binaire semafoor. Je moet een semafoor zien als een vergunning verlener, en een binaire semafoor kun je zien als een vergunning verlener met 1 vergunning.

Nee, je kunt een binaire semafoor zien als een langzame mutex omdat ie teveel overhead verspilt door integers te tellen ipv simpelweg bitwise boolean te schakelen. Semaphores zijn nutteloos totdat er een size van 2 of meer op komt.

Dat dit begrip onder win32 verkeerd gebruikt wordt, vind ik nogal misleidend.

Ach zoals ik al aangaf maken de semantics met EnterCriticalSection en LeaveCriticalSection veel goed, omdat ze more-or-less duidelijk maken dat het stuk code ertussen een kritieke sectie is volgens jouw opvatting.

[curry684]

Verwijderd schreef op 12 oktober 2002 @ 15:19:
curry : dat hangt natuurlijk van je ontwerp af. Het GINA component wat ik mag beheren zit nou eenmaal zo in elkaar dat 'ie die critical sections maar voor 1 blok code gebruikt (het zijn er maar 2 overigens). Verder wel een boel mutexen/events/semaforen, zoals je zou verwachten met dat soort redelijk complexe multithreaded code.
Ook een hell om te debuggen overigens (comp crasht nogal vaak als je GINA iets echt fout doet )

Geinig, heb een tijdje terug de docs van GINA doorgelezen en me uren af zitten vragen waarom iemand daar ooit iets mee zou schrijven... enlighten me?

btw. voor echte wilde pret met synchronization objects en semaphores moet je eens nadenken over hoe je een dynamische threadpool moet bouwen, dwz. een threadpool die dynamisch threads bij kan jongen als dat nodig is en ze af kan stoten als er teveel ongebruikt rondzweven.

[Verwijderd]

De GINA implementatie die wij gebruiken is om een WindowsNT werkstation aan te laten loggen op een OS/2 server (je snapt : dat kan MSGINA dus niet). Hij stuurt authentication requests naar een serverside component op OS/2, genaamd SMA (System Management Agent). De GINA wordt ook gebruik voor systeemonderhoud (softwaredistributie bv.). Hij logt daan automatisch de onderhoudsgebruiker aan op het systeem, die dan weer een onderhoudsscript start. WAT de GINA precies verder allemaal nog doet ga ik hier niet uitlegen. Het is proprietary software van mn werkgever en bovendien wordt dat een lang verhaal
Grappig bijverschijnsel van deze GINA is wel dat NT er stabieler op is geworden. We hebben een testruimte met 200PC's waarvan sommige gewoon met de MSGINA draaien, en die crashen VEEL vaker dan die met onze eigen GINA. Die MSGINA bakjes draaien overigens verder een subset van de software die de machines met onze eigen GINA draaien, dus daar zal het verschil em niet in zitten...

[Verwijderd]

Zo'n threadpool lijkt volgens mij erg op een connection pool voor bijvoorbeeld socket connections, of niet? Dat wordt ook vaak multithreaded opgelost...
Heb ik nog nooit gemaakt trouwens, ben nu gewoon bezig met een frameworkje voor allerhande connections (socket,named pipe, netbios), daar heb ik bij tijd en wijle al moeite genoeg mee

edit:
Ik vind trouwens dat het in zn algemeenheid niet meevalt om behoorlijke reusable code te schrijven (anders dan via copy+paste)... Daar worden toch heel andere eisen aan gesteld dan aan project-specific code

[Alarmnummer]

curry684 schreef op 12 oktober 2002 @ 15:20:
Nee, je kunt een binaire semafoor zien als een langzame mutex omdat ie teveel overhead verspilt door integers te tellen ipv simpelweg bitwise boolean te schakelen. Semaphores zijn nutteloos totdat er een size van 2 of meer op komt.

Ik vind snelheid meestal een vrij slecht argument om de werking van een bepaalde constructie onderuit te halen. Een binaire semafoor kan je dus uitstekend zien als een mutex constructie. Ik merk het vaker dat c(++) programmeurs extreem gebrand zijn op snelheid/geheugenverbruik. Ik ben op dit moment veel bezig met een combinatie van een functionele en object georienteerde taal, en ik weet dat er in veel opzichten veel overhead is. Maar als ik eerlijk ben interesseerd me dat niet echt veel, omdat ik dus van fantistisch mooie constructies bezig kan gaan en me daarom vaak alleen nog maar bezig hoef te houden met de essentie ipv alle rompslomp erom heen. Ik weet hoe eng dit zal zijn voor een die-hart c++ programmeur, maar ik kan het je echt aanraden.

*was ook bitneuker totdat hij het licht heeft gezien*

[curry684]

Alarmnummer schreef op 12 oktober 2002 @ 15:54:
Ik vind snelheid meestal een vrij slecht argument om de werking van een bepaalde constructie onderuit te halen. Een binaire semafoor kan je dus uitstekend zien als een mutex constructie. Ik merk het vaker dat c(++) programmeurs extreem gebrand zijn op snelheid/geheugenverbruik. Ik ben op dit moment veel bezig met een combinatie van een functionele en object georienteerde taal, en ik weet dat er in veel opzichten veel overhead is. Maar als ik eerlijk ben interesseerd me dat niet echt veel, omdat ik dus van fantistisch mooie constructies bezig kan gaan en me daarom vaak alleen nog maar bezig hoef te houden met de essentie ipv alle rompslomp erom heen. Ik weet hoe eng dit zal zijn voor een die-hart c++ programmeur, maar ik kan het je echt aanraden.

*was ook bitneuker totdat hij het licht heeft gezien*

Wat is dit nu weer voor je reinste onzin... je vindt dus het gebruik van een semaphore als mutex aanvaardbaar ondanks het feit dat een mutex sneller, eenvoudiger en duidelijker functioneert (je code wordt er allesbehalve begrijpelijk door als je je overal af moet vragen hoe groot de semaphore is die je aan het locken bent...). Kun je even op een fatsoenlijke manier deze 3 argumenten tegen het gebruik van binaire semaphores ontkrachten in plaats van een filosofisch nonsens-verhaal waarin je een hoop onzinnige en niet onderbouwde vooroordelen over mij opentrekt?

[curry684]

Verwijderd schreef op 12 oktober 2002 @ 15:41:
Zo'n threadpool lijkt volgens mij erg op een connection pool voor bijvoorbeeld socket connections, of niet? Dat wordt ook vaak multithreaded opgelost...
Heb ik nog nooit gemaakt trouwens, ben nu gewoon bezig met een frameworkje voor allerhande connections (socket,named pipe, netbios), daar heb ik bij tijd en wijle al moeite genoeg mee

Connection pools worden meestal opgelost zonder threadpool door simpelweg 'on-demand' threads aan te maken, en dat is ook best te vergeven ondanks dat een threadje aanmaken al snel 30ms overhead kost op mijn celeron@478.

Zodra je echter zonder delays 100 multithreaded connecties volledig tegelijk wil kunnen ontvangen heb je dan dus de keuze tussen 3000ms lockup of simpelweg al 100 threads klaar hebben staan die je constant reused. Dit is een heel hypothetisch voorbeeld voor een socket-connection maar voor complexe distributed application servers (mijn business ) moet je echt aan de threadpools geloven om het zaakje vloeiend te houden.

edit:
Ik vind trouwens dat het in zn algemeenheid niet meevalt om behoorlijke reusable code te schrijven (anders dan via copy+paste)... Daar worden toch heel andere eisen aan gesteld dan aan project-specific code

Tja in mijn branche is non-reusable code redelijk per definitie non-usable code

[Alarmnummer]

Ik heb er eerlijk gezegd helemaal geen zin in.

[curry684]

Alarmnummer schreef op 12 oktober 2002 @ 16:20:
Ik heb er eerlijk gezegd helemaal geen zin in.

Als je te zwak bent om een discussie aan te gaan moet je niet beginnen met mensen openbaar denigrerend aan te spreken.

Ik heb je post echt 5 keer doorgelezen voordat ik reageerde, en kon me toen nog steeds niet aan de indruk onttrekken dat jij als grote visionair een domme ondergeschikte prutser terecht zat te wijzen over dat ie zich niet moest bezighouden met het Hogere Doel van het Programmeren omdat ie daar te dom en bekrompen voor was.

Ik had daar graag een gezonde discussie over gehad, jammer dat je daar de ballen niet voor hebt. Nuff said.

[Alarmnummer]

curry684 schreef op 13 oktober 2002 @ 16:06:
[...]

Als je te zwak bent om een discussie aan te gaan moet je niet beginnen met mensen openbaar denigrerend aan te spreken.

Ik heb je post echt 5 keer doorgelezen voordat ik reageerde, en kon me toen nog steeds niet aan de indruk onttrekken dat jij als grote visionair een domme ondergeschikte prutser terecht zat te wijzen over dat ie zich niet moest bezighouden met het Hogere Doel van het Programmeren omdat ie daar te dom en bekrompen voor was.

Volgens mij heb ik een gevoelige snaar geraakt.

Ik had daar graag een gezonde discussie over gehad, jammer dat je daar de ballen niet voor hebt. Nuff said.

[D2k]

heren: vecht dat over de mail uit
niet in dit topic iig

[.oisyn]

D2k: niet mee eens
* .oisyn ziet ook graag uit naar de argumenten van Alarmnummer
wel zonder flames overigens

(en het is tenslotte mijn draadje )

[Alarmnummer]

Mijn reactie was hierop:

Nee, je kunt een binaire semafoor zien als een langzame mutex omdat ie teveel overhead verspilt door integers te tellen ipv simpelweg bitwise boolean te schakelen. Semaphores zijn nutteloos totdat er een size van 2 of meer op komt.

En ik vind dus snelheid een slecht argument om een bepaalde constructie onderuit te halen.

Goeie argumenten waarom een binaire semafoor slechter is dan een mutex:

-het is minder duidelijk omdat je bij een mutex het echt hebt over mutual exclusion, en dat hoeft bij een semafoor niet zo te zijn (dit geeft hij ook als antwoord in zijn reply hierop trouwens)

-de syntax van een mutex kan zal duidelijker zijn dan een semafoor. lock/unlock tov up en down.

-bij een mutex kan je een foutmelding opwerpen als je een 'unlockte' mutex nog een keer gaat unlocken. BIj een semafoor wordt geen foutmelding opgeworpen omdat je dus gewoon 'een vergunning toevoegd' en daar is niets mis mee.

Met deze argumenten kwam hij in die reply niet aanzetten, en vandaar dus mijn verhaal over 'anti-snelheid' en c++ bitneukers. Vooral omdat ik vroeger ook zo gebrand was op alles onder controle te houden en alles zo snel mogelijk te krijgen (en dat ik ook een enorme bitneukers was).

En de rest van mijn reacties waren misschien iets minder 'gepast'. Maar het was mijn reactie op zijn zwak/ballen verhaal.

[curry684]

Met deze argumenten kwam hij in die reply niet aanzetten, en vandaar dus mijn verhaal over 'anti-snelheid' en c++ bitneukers. Vooral omdat ik vroeger ook zo gebrand was op alles onder controle te houden en alles zo snel mogelijk te krijgen (en dat ik ook een enorme bitneukers was).

Erfenis van C-64 en Amiga programmeren Maar zoals je zag in mijn voorbeeld over threads aanmaken (3 seconden delay op een Celly-480 is realistisch) is snelheidswerk nog steeds belangrijk op z'n tijd. Tijdje terug heb ik een routine van een collega herschreven die de hele toko af zat te remmen... door wat hard-pointered chopwerk 1 routine 40x (!!!) sneller gemaakt, en daarmee een aantal toepassingen eromheen 2 tot 3 keer. En hierdoor gingen bepaalde delays wel van 10 minuten naar 5 minuten op een P3-550. In een ander geval heb ik op een vergelijkbare manier in een web-applicatie een uploadsnelheid van 7 minuten omlaaggebracht naar strak 1 minuut door wat encodingroutines wat 'efficienter' te herschrijven. Vertel mij niets over het nut van letten op snelheid in hedendaagse applicaties...

En verder, ik geloof dat ik hierboven ergens iets in de richting van een excuus over overhaaste conclusies zag staan, geaccepteerd bij deze

[Alarmnummer]

We zullen het dan weer even helemaal goedmaken

Ik heb op dit moment de luxe dat ik me nooit over snelheid druk hoef te maken. Maar toen ik veel met grafische dingen bezig was, was ook blij met een:
y>>8+y>>6+x ipv y*320+x om de offset te bepalen (mode X = 320x200 8 bits kleuren) en een 32 copy, ipv een 8 of 16. Alleen maar omdat dat sneller is. Het ligt er inderdaad aan hoe vaak iets per seconde wordt aangeroepen.

[curry684]

Alarmnummer schreef op 14 oktober 2002 @ 00:07:
Het ligt er inderdaad aan hoe vaak iets per seconde wordt aangeroepen.

En om weer bijna helemaal terug on-topic te komen: mutexes hebben de neiging verdomd vaak gebruikt te worden, eens in de 10 minuten is synchronizatie lang niet zo boeied als met 20 realtime concurrent threads die staan te knokken om een shared-dataclass

[curry684]

.oisyn schreef op 13 oktober 2002 @ 19:45:
wel zonder flames overigens

Geen flames gezien, alleen wat strak gerichte opmerkingen recht op de man af beiderzijds