[win32/c++] pthreads en ::Sleep() ?

[12_0_13]

Hallo

ik heb een (win32 console) appje dat multithreaded is, en nu moet een bepaalde thread om de 20 milliseconden een event genereren. De thread is een pthread, geembed in een classe volgens het voorbeeld.

C++:

char c;
while(true)
{
    int id = rand()%33;
    Event * e = new Event();
    e->i=c;
    printf("Generated timed event: %d\n", c);
    env.addEvent(e);
    ::Sleep(20);
}

Een andere thread leest het keyboard uit met een

C++:

char c;
while(std::cin.get(c))
{   
    int id = rand()%33;
    Event * e = new Event();
    e->i=c;
    printf("Generated button event: %d\n", c);
    env.addEvent(e);
}

env is hier een classe met een methode die gemutexed een event toevoegd aan de queue.

Het rare is, deze applicatie crasht na een tijdje. Voglens de dump van dr watson is het een c000005 error, een acces violation. Ik heb alleen geen idee wat die crash kan veroorzaken. Er is geen memory leaking, want anders had ik dat wel gezien in de taskmanager.

Weet iemand hoe ik dit kan uit-debuggen, of doe ik dingen (win Sleep mixen met pthreads) die nooit mogen, en zoja, is hier een goede (en snelle) variant voor?

[ Voor 9% gewijzigd door 12_0_13 op 03-06-2004 15:46 ]

[.oisyn]

waaruit trek je de conclusie dat Sleep ook echt het probleem is? Ik denk eerder dat het probleem zit in env.

Waarom gebruik je trouwens geen debugger? Dan weet je precies waar het fout gaat.

[12_0_13]

Ja ik zou het graag debuggen, maar dat kan nu wegens burocratische redenen niet (compileren op bak1 -> runnen op bak 2 met specifieke hardware) Ik heb wel WinDBG geinstalleerd maar dat snap ik nog niet zo goed. Verder heb ik dus die dumpfile, maar echt interessant info haal ik daar niet uit Ik kan hem eventueel wel posten maar ik weet niet of dat zoveel zin heeft.

Ik hoopte dat iemand mij zou kunne vertellen dat hiet NIET aan sleep lag

env ziet er zo uit:

C++:

// EventEnvironment.cpp: implementation of the EventEnvironment class.

#include "EventEnvironment.h"
#include <iostream>
/**
 * Constructor. Sets the inits the mutex and empty semaphore
 */
EventEnvironment::EventEnvironment()
{
      sem_init(&mutex, NO_SHARE, 1);
      sem_init(&empty, NO_SHARE, 0);
}

/** 
 * Destructor. 
 */ 
EventEnvironment::~EventEnvironment()
{
    //nothing here yet
}

/**
 * Retrieves the frontmost event from the eventqueue (currently its an integer :)
 */ 
Event * EventEnvironment::getEvent()
{
    //Get the lock
    sem_wait(&mutex);   

    //Get the first element
    Event * e = eventQueue.front();

    //Remove the first element
    eventQueue.pop_front();

    std::cout << "length queue: " << eventQueue.size() << std::endl;
    //Release the lock
    sem_post(&mutex);
    
    //Return the element
    return e;
}


/**
 * Adds an event to the queue. This is done by external forces, 
 * like button input generators.
 */
void EventEnvironment::addEvent(Event * e)
{
    //get the lock
    sem_wait(&mutex);   
    
    //store the event
    eventQueue.push_back(e);

    //release the lock
    sem_post(&mutex);
    
    //signal that an event is added 
    sem_post(&empty);
}

/** 
 * Wait for incoming events
 */ 
void EventEnvironment::waitForEvent()
{
    //wait for events (empty should be signalled)
    sem_wait(&empty);
}

[ Voor 14% gewijzigd door 12_0_13 op 03-06-2004 16:00 ]

[.oisyn]

12_0_13 schreef op 03 juni 2004 @ 15:55:
Ja ik zou het graag debuggen, maar dat kan nu wegens burocratische redenen niet (compileren op bak1 -> runnen op bak 2 met specifieke hardware)

Daar hebben ze zoiets als remote debugging voor uitgevonden
En wist je al dat je dump files kunt openen in VC++?

Verder ziet je code er volgens mij wel goed uit, hoewel ik niet echt bekend ben met pthreads. Waarom is de 3e parameter van de init van mutex 1, terwijl die bij empty 0 is? Is dat de initiele staat?

[12_0_13]

Ja dat klopt, das de initiele staat. Bij een mutex moet je die dus nog kunnen verlagen naar 0, bij de empty just niet. (want je moest eerst wat produceren -> waarde omhoog, voordat er geconsumeerd kan worden->waarde omlaag)

Ik zla eens zoeken naar remote debugging, bedankt alvast, ik kom er nog wel op terug iig

pthreads is een posix threads implementatie die je zowel voor linux als windows kan gebruiken en ik vind hem erg duidelijk

[curry684]

12_0_13 schreef op 03 juni 2004 @ 16:08:
Ja dat klopt, das de initiele staat. Bij een mutex moet je die dus nog kunnen verlagen naar 0, bij de empty just niet. (want je moest eerst wat produceren -> waarde omhoog, voordat er geconsumeerd kan worden->waarde omlaag)

Ik zla eens zoeken naar remote debugging, bedankt alvast, ik kom er nog wel op terug iig

pthreads is een posix threads implementatie die je zowel voor linux als windows kan gebruiken en ik vind hem erg duidelijk

Ik vind het een enorm lelijke implementatie die ik met veel tegenzin te goed heb moeten leren voor OpenVMS, en waarover ik nog via mail ruzie met een van de core developers heb gehad over een fundamentele bug die occasioneel crashes veroorzaakt

Pak gewoon lekker CreateThread en CreateMutex onder Windows tussen #ifdef WIN32 regels zou ik zeggen Sleep is iig zeker niet het probleem, dat durf ik je wel te verzekeren

[12_0_13]

Joehoe! het remote debuggen werkt !! NA wat DLL-verplaatsingen en honderden messagesboxes met waarschuwingen dat de lines niet hetzelfde zijn in DLL's ben ik nu to al in ieder geval tegen 1 bug aangelopen. (misschien niet DE bug, maar iig wel een bug)

Wat wil het geval: ik meet de tijd die gebruikt wordt voor functies, en die druk ik netjes af naar de cout. Om het een beetje leesbaar te maken, ging ik de outputstream imbue-en met een locale, en dit is waarshcnlijk niet thread safe. Ik heb de betreffende code verwijderd en ben vrolijk aan het testen nu.

offtopic:
@curry
Wat is die enorme bug dan die erin zit/zat, en zou ik daar last van kunnen krijgen?
En waarom is die implementatie zo lelijk? Alleen zeggen dattie lelijk is en suckt is natuurlijk erg makkelijk

[reddog33hummer]

Je kan in windows ook gebruik maken van een critical section.
Dan wordt de mutex om je aanroep heen gezet.

[.oisyn]

12_0_13 schreef op 03 juni 2004 @ 16:56:
En waarom is die implementatie zo lelijk? Alleen zeggen dattie lelijk is en suckt is natuurlijk erg makkelijk

Nou ja zoals gezegd heb ik er niet zoveel ervaring mee, maar ze zouden bijvoorbeeld eens iets aan de naamgeving kunnen doen (maar dat vind ik sowieso wel van alle *nix APIs )

[Verwijderd]

curry684 schreef op 03 juni 2004 @ 16:30:
Ik vind het een enorm lelijke implementatie die ik met veel tegenzin te goed heb moeten leren voor OpenVMS, en waarover ik nog via mail ruzie met een van de core developers heb gehad over een fundamentele bug die occasioneel crashes veroorzaakt

Vlam vlam pthreads is vrij abstract omdat het een hardware onafhankelijke library is. En een fundamentele bug in pthreads die er na zo'n 10 jaar nog niet uitgehaald is; vertel? (Fundamenteel lijkt me een design-fout in de API)

Pak gewoon lekker CreateThread en CreateMutex onder Windows tussen #ifdef WIN32 regels zou ik zeggen

Zelf een portability layer schrijven is pure ellende en de oorzaak van moeilijk op te sporen platvorm-afhankelijke bugs. Een van de grootste nonos bij het ontwikkelen van portable software; alleen doen als het echt niet anders kan

offtopic:
OSS heeft het je toch wel aangedaan, niet? Je sig b.v. is pure propaganda, bij OSS blijft namelijk i.t.t. bij Public Domain het auteursrecht behouden; code is en blijft eigendom van de auteur (tenzij die expliciet het copyright overdraagt). Licencies als de GPL kunnen niet bestaan zonder onderliggend copyright.

[curry684]

Verwijderd schreef op 03 juni 2004 @ 18:49:
[...]

Vlam vlam pthreads is vrij abstract omdat het een hardware onafhankelijke library is. En een fundamentele bug in pthreads die er na zo'n 10 jaar nog niet uitgehaald is; vertel? (Fundamenteel lijkt me een design-fout in de API)

pthreads is lelijk omdat je alles zelf moet doen wat voor de hand ligt. Een condition moet je zelf nog een mutex aanhangen terwijl dat per definitie nodig is, state changes in conditions moet je zelf broadcasten terwijl dat per definitie nodig is etc. Het doet imho niet wat een API hoort te doen: de functionaliteit wegencapsuleren zodat je er als implementer niet meer naar om hoeft te kijken. Bij pthreads blijf je de code verdenken van iedere fout, terwijl je bij Win32 bijvoorbeeld zeker weet dat het niet in de synchronizatie zit.

De fundamentele bug was een miniem synchronizatiegat in mutexes die in extreem uitzonderlijke gevallen kon toestaan dat de mutex niet 'mutual exclusive' was. Hoogst uitzonderlijk schijnbaar, maar ik kreeg erdoor in 24/7 software wel 2~3 keer per maand een klacht over access violations op productie. Erg laakbaar.... weet niet overigens of dat puur de OpenVMS/Alpha implementatie betrof, waarschijnlijk wel. Zegt nog immer genoeg over de 'portability' van de API, op een ander platform kan je code nog immer spontaan instabiel worden

offtopic:
OSS heeft het je toch wel aangedaan, niet? Je sig b.v. is pure propaganda, bij OSS blijft namelijk i.t.t. bij Public Domain het auteursrecht behouden; code is en blijft eigendom van de auteur (tenzij die expliciet het copyright overdraagt). Licencies als de GPL kunnen niet bestaan zonder onderliggend copyright.

offtopic:
Daar zegt m'n sig toch niets over? De tekst stelt alleen dat je er als ontwikkelaar geen cent aan kunt verdienen, en dat het om die reden te hopen is dat open source software niet te populair wordt, omdat kwalitatief hoogstaande maar dure software omdat er mensen hun kinderen van moeten voeden dan ondergesneeuwd raakt onder veruit inferieure gratis software. Open Source is net Groen Links: leuk en handig zolang het maar oppositie voert en de regeerpartijen wakkerschud. Je moet er niet aan denken dat het gaat regeren.

M'n sig is overigens al vaak genoeg reden geweest tot offtopic reacties, dus laten we dat bij deze thread maar niet gaan doen

[Verwijderd]

curry684 schreef op 03 juni 2004 @ 22:00:
pthreads is lelijk omdat je alles zelf moet doen wat voor de hand ligt. Een condition moet je zelf nog een mutex aanhangen terwijl dat per definitie nodig is, state changes in conditions moet je zelf broadcasten terwijl dat per definitie nodig is etc.

Er is tot in den treure over deze beslissingen gediscussieërd: conditions hangen niet aan een mutex omdat dat problemen kan opleveren met cancelpoints i.s.m. cleanup-handlers. Broadcasten gaat niet automatisch omdat je een keuze hebt tussen broadcasting (wekt alle consumer threads) en signaling (wekt een consumer thread).

Het doet imho niet wat een API hoort te doen: de functionaliteit wegencapsuleren zodat je er als implementer niet meer naar om hoeft te kijken. Bij pthreads blijf je de code verdenken van iedere fout, terwijl je bij Win32 bijvoorbeeld zeker weet dat het niet in de synchronizatie zit.

Ik denk dat dat een cultuurkwesie is, ik heb bij windows het idee dat ik veel te zwaar geschut moet uitpakken om een probleem op te lossen (mutexen i.p.v. spinlocks) of dat ik optimalisaties mis (rwlocks).

Zegt nog immer genoeg over de 'portability' van de API, op een ander platform kan je code nog immer spontaan instabiel worden

Het zegt wat over de implementatie maar niet over de portability van de API, je gebruikt immers de zelfde function-calls onder OpenVMS als onder Windows of Linux.

[curry684]

Verwijderd schreef op 03 juni 2004 @ 23:17:
[...]

Er is tot in den treure over deze beslissingen gediscussieërd: conditions hangen niet aan een mutex omdat dat problemen kan opleveren met cancelpoints i.s.m. cleanup-handlers.

Waarom kan Windows dat wel zelf?

Broadcasten gaat niet automatisch omdat je een keuze hebt tussen broadcasting (wekt alle consumer threads) en signaling (wekt een consumer thread).

Waarom kan Windows dat wel zelf?

Ik denk dat dat een cultuurkwesie is, ik heb bij windows het idee dat ik veel te zwaar geschut moet uitpakken om een probleem op te lossen (mutexen i.p.v. spinlocks)

CriticalSection (Included in Windows XP, Windows 2000 Professional, Windows NT Workstation, Windows Me, Windows 98, and Windows 95 volgens de docs) is gewoon een spinlock, en wordt aangeraden altijd te gebruiken in plaats van mutexes waar mogelijk.

of dat ik optimalisaties mis (rwlocks).

rwlocks missen inderdaad, best jammer. Maja, niets kan compleet zijn, zo mis ik in pthreads fatsoenlijke cross-process synchronization support en waitable timers.

Het zegt wat over de implementatie maar niet over de portability van de API, je gebruikt immers de zelfde function-calls onder OpenVMS als onder Windows of Linux.

Ik vind het nogal wat zeggen over de portability van de API als dezelfde functie onder VMS anders gedraagt of zelfs knalt en onder Windows of Linux niet. Dat noemen we 'niet portable'.

Schrijf dan in C++ gewoon een mutex-class met eenduidige interface die de platformspecifieke versie encapsuleert, kun je tenminste van op aan en kost je welzeker ~10 minuten werk. En tis nog sneller ook in het algemeen (kijk, heb je je optimalisaties )

[Verwijderd]

curry684 schreef op 03 juni 2004 @ 23:25:
Waarom kan Windows dat wel zelf?

Is er een cleanup mechanisme voor threads in windows?

Waarom kan Windows dat wel zelf?

Ik dacht dat windows altijd signaled en nooit broadcast?

CriticalSection (Included in Windows XP, Windows 2000 Professional, Windows NT Workstation, Windows Me, Windows 98, and Windows 95 volgens de docs) is gewoon een spinlock, en wordt aangeraden altijd te gebruiken in plaats van mutexes waar mogelijk.

Hmm, ik dacht dat er weinig winst te behalen was met CriticalSections in windows maar ik kan daar nergens meer referenties naar vinden; puntje voor jou

rwlocks missen inderdaad, best jammer. Maja, niets kan compleet zijn, zo mis ik in pthreads fatsoenlijke cross-process synchronization support en waitable timers.

Cross-process syncing is geen thread syncing (andere adress space) en hoort dus niet in een thread library. Waitable timers zijn niet efficiënt en tegelijk portable te implementeren, daarvoor zijn de hardware verschillen te groot.

Ik vind het nogal wat zeggen over de portability van de API als dezelfde functie onder VMS anders gedraagt of zelfs knalt en onder Windows of Linux niet. Dat noemen we 'niet portable'.

Het zegt niets over de API-specificatie maar over de implementatie daarvan, als die implementatie goed was zou de zelfde functie zich wel identiek gedragen op verschillende platforms.

Schrijf dan in C++ gewoon een mutex-class met eenduidige interface die de platformspecifieke versie encapsuleert, kun je tenminste van op aan en kost je welzeker ~10 minuten werk. En tis nog sneller ook in het algemeen (kijk, heb je je optimalisaties )

Uhh, waarom is het wel een goed idee om dat in C++ te doen maar problematisch in C (pthreads doet onder windows namelijk niets anders dan CreateMutex e.d. encapsuleren)?

[curry684]

Verwijderd schreef op 03 juni 2004 @ 23:46:
[...]

Is er een cleanup mechanisme voor threads in windows?

Uh ja? Als in: wanneer welke cleanup, maar volgens mij wel?

[...]

Ik dacht dat windows altijd signaled en nooit broadcast?

Bij CreateEvent zit een boolean parameter 'AutoReset'. Een AutoReset event signalled 1 waiter. Een manual reset event released alle waiters. Op een ManualReset event kun je ook met PulseEvent alle waiters loslaten en daarna automatisch laten resetten.

Hmm, ik dacht dat er weinig winst te behalen was met CriticalSections in windows maar ik kan daar nergens meer referenties naar vinden; puntje voor jou

2 dan na die events hierboven

Cross-process syncing is geen thread syncing (andere adress space) en hoort dus niet in een thread library. Waitable timers zijn niet efficiënt en tegelijk portable te implementeren, daarvoor zijn de hardware verschillen te groot.

Voor Windows is het dezelfde address space, wat je tig keer meer flexibiliteit geeft. Dat het niet in een thread library thuishoort is natuurlijk onzin: je synced nog steeds meer threads. Dat je door het native OS te omzeilen die functionaliteit niet kunt aanbieden is je eigen fout

Een waitable timer lijkt mij redelijk portable maar laat ik me verder niet over uit bij gebrek aan inhoudelijke kennis erover

Ik was 'm trouwens nog zowat vergeten, maar de voornaamste feature die ik mis in pthreads heet WaitForMultipleObjects. Die functie is heilig en ik wil echt niet meer teruglezen wat een achterlijke code ik heb moeten schrijven om om dat gemis heen te werken

En laten we de 'timeout' parameter op de Wait-functies niet vergeten, waarmee je tot ~10ms precies kunt wachten op een signal van een van de objects waarop je wacht.

Het zegt niets over de API-specificatie maar over de implementatie daarvan, als die implementatie goed was zou de zelfde functie zich wel identiek gedragen op verschillende platforms.

Klopt op zich, maar ken je het verschijnsel dat mensen die ooit in een Opel een aanrijding hebben gehad een hekel hebben aan Opels? Was niet echt een argument overigens, bracht ik enkel erbij als reden waarom ik persoonlijk nog een grotere hekel heb aan pthreads dan alleen de interface.

Uhh, waarom is het wel een goed idee om dat in C++ te doen maar problematisch in C (pthreads doet onder windows namelijk niets anders dan CreateMutex e.d. encapsuleren)?

pthreads doet een vertaalslag van een omslachtige interface naar de native interface en is dus langzamer. Je C++ functies zullen inline vertalen naar basic functies tenzij je alle functionaliteit van pthreads native wilt aanbieden (zoals non-recursive mutexes )

[ Voor 6% gewijzigd door curry684 op 04-06-2004 00:05 ]

[Verwijderd]

curry684 schreef op 04 juni 2004 @ 00:01:
Uh ja? Als in: wanneer welke cleanup, maar volgens mij wel?

De cleanup die er plaatsvindt indien een thread gecancelled wordt door een andere thread (pthread_cleanup_push en pthread_cleanup_pop).

Bij CreateEvent zit een boolean parameter 'AutoReset'. Een AutoReset event signalled 1 waiter. Een manual reset event released alle waiters. Op een ManualReset event kun je ook met PulseEvent alle waiters loslaten en daarna automatisch laten resetten.

Mja, de vraag is dus maar wat een beter API-design is, default signaling en manual broadcasting en een nog meer voodoo of het KISS-prinicipe (Keep It Simple, Stupid); vanuit het al eerder aangesproken cultuurverschil gaat als POSIX-nerd mijn voorkeur uiteraard uit naar KISS

Voor Windows is het dezelfde address space, wat je tig keer meer flexibiliteit geeft. Dat het niet in een thread library thuishoort is natuurlijk onzin: je synced nog steeds meer threads. Dat je door het native OS te omzeilen die functionaliteit niet kunt aanbieden is je eigen fout

Een process dan wel ook iets dat gescheduled wordt e.d. maar verschilt nu net fundamenteel van een thread doordat alle threads van een process in de context van dat process draaien, terwijl elk process een individuele context heeft. Daardoor kunnen processen elkaar niet voor de voeten lopen door in elkaars adresruimte te schrijven (waardoor je slechts zelden processen hoeft te syncen). (Als je dat als OS-fabrikant in de vijfde generatie van je OS nog niet goed voor elkaar hebt is dat je ook aan te rekenen.)

Ik was 'm trouwens nog zowat vergeten, maar de voornaamste feature die ik mis in pthreads heet WaitForMultipleObjects. Die functie is heilig en ik wil echt niet meer teruglezen wat een achterlijke code ik heb moeten schrijven om om dat gemis heen te werken

Signalhandlers schrijven is belachelijk?

edit:
Vergeten: de default-mutex van pthreads in non-recursive, zowel onder windows als onder linux.

[ Voor 5% gewijzigd door Verwijderd op 04-06-2004 00:45 ]

[Soultaker]

Verwijderd schreef op 04 juni 2004 @ 00:30:
Signalhandlers schrijven is belachelijk?

Ik vind signal handlers echt afgrijselijk, zeker in een multithreaded omgeving. Dan heb ik toch echt liever nette afzonderlijk threads.

[curry684]

Verwijderd schreef op 04 juni 2004 @ 00:30:
[...]

De cleanup die er plaatsvindt indien een thread gecancelled wordt door een andere thread (pthread_cleanup_push en pthread_cleanup_pop).

Nee, als je een thread letterlijk afschiet worden niet alle objects/handles gereleased. Maja: TerminateThread is a dangerous function that should only be used in the most extreme cases.

Ik heb die functie dan ook nog nooit nodig gehad

Mja, de vraag is dus maar wat een beter API-design is, default signaling en manual broadcasting en een nog meer voodoo of het KISS-prinicipe (Keep It Simple, Stupid); vanuit het al eerder aangesproken cultuurverschil gaat als POSIX-nerd mijn voorkeur uiteraard uit naar KISS

Mjah, CreateEvent heeft 4 parameters: name, autoreset, initial state, security context. Da's volgens mij simplers for the stupids dan de pthread-variant, maar daarover mogen we van mening verschillen

Een process dan wel ook iets dat gescheduled wordt e.d. maar verschilt nu net fundamenteel van een thread doordat alle threads van een process in de context van dat process draaien, terwijl elk process een individuele context heeft. Daardoor kunnen processen elkaar niet voor de voeten lopen door in elkaars adresruimte te schrijven (waardoor je slechts zelden processen hoeft te syncen). (Als je dat als OS-fabrikant in de vijfde generatie van je OS nog niet goed voor elkaar hebt is dat je ook aan te rekenen.)

Ho, nu begrijp je me verkeerd. Vanzelfsprekend bevinden processen zich in andere address spaces en kunnen ze niet bij mekaar modderen. Echter, er is ook een gezamenlijke kernel namespace, waarin alle named mutexes, pipes, events, waitable timers, memory mappings, processes etc. zich bevinden, en je ze dus afhankelijk van je security context al of niet uit op kunt vragen. Op die manier kunnen 2 processen dus om dezelfde mutex vragen en daarop synchronizeren, bijvoorbeeld om een stuk 'shared memory' te syncen. Mag ik vragen hoe je onder Linux van plan was om 2 processen gesynchroniseerd een stuk geheugen te laten sharen, en hoeveel code eromheen komt te liggen (onder Win32 4 calls in beide processen ongeveer).

Signalhandlers schrijven is belachelijk?

En hoe ga ik nu met signal handlers tegelijk op 2 events, een mutex en een thread wachten totdat er 1 signaled is? Volgens mij heb je niet helemaal door wat WaitForMultipleObjects doet

edit:
Vergeten: de default-mutex van pthreads in non-recursive, zowel onder windows als onder linux.

Windows kent geen non-recursive mutexes gelukkig. Gebruik van een non-recursive mutex is een tijdbom op een deadlock waiting to happen.

[Verwijderd]

curry684 schreef op 04 juni 2004 @ 01:10:
Mag ik vragen hoe je onder Linux van plan was om 2 processen gesynchroniseerd een stuk geheugen te laten sharen, en hoeveel code eromheen komt te liggen (onder Win32 4 calls in beide processen ongeveer).

Door een stukje geshared memory te allocaten en een semafoortje te vlaggen (er zijn ook andere methodes voor IPC)

En hoe ga ik nu met signal handlers tegelijk op 2 events, een mutex en een thread wachten totdat er 1 signaled is? Volgens mij heb je niet helemaal door wat WaitForMultipleObjects doet

D.m.v. cascaded signals kan ik veel bereiken. Daarnaast is het voor mij nogal ondoorzichtig waarom je signal-achtige events enerzijds en blote mutexen anderzijds per cé in de zelfde handler moet afhandelen, dat lijkt me nogal complexe handlers opleveren.

[ Voor 3% gewijzigd door Verwijderd op 04-06-2004 03:15 ]

[curry684]

Verwijderd schreef op 04 juni 2004 @ 03:14:
[...]

Door een stukje geshared memory te allocaten en een semafoortje te vlaggen (er zijn ook andere methodes voor IPC)

Is een 'semafoortje' dan wel cross-process? En je gaat voorbij aan de vraag over de hoeveelheid code

[...]

D.m.v. cascaded signals kan ik veel bereiken. Daarnaast is het voor mij nogal ondoorzichtig waarom je signal-achtige events enerzijds en blote mutexen anderzijds per cé in de zelfde handler moet afhandelen, dat lijkt me nogal complexe handlers opleveren.

Complex? Nee hoor, hier een fictieve main loop van een thread die data opspaart en zodra mogelijk doorkopieert richting een ander proces:

C++:

while(true)
{
  HANDLE l_Events[3] = { ShutdownEvent->GetHandle(),
                         NewDataEvent->GetHandle(), SharedMutex->GetHandle() };

  switch(WaitForMultipleObjects(3, l_Events, FALSE, INFINITE))
  {
  case WAIT_OBJECT_0:
    CleanupThreadAndDie();
    break;
  case WAIT_OBJECT_0 + 1:
    FetchAndStoreNewData();
    break;
  case WAIT_OBJECT_0 + 2:
    CopyStoredDataToSharedMemory();
    break;
  default:
    // Either WAIT_FAILED or the mutex was abandoned
    ShutdownWithTerminalError();
    break;
  }
}

En nu jij in net zoveel code, en net zo waterdicht gesynchroniseerd

[Verwijderd]

curry684 schreef op 04 juni 2004 @ 09:52:
Is een 'semafoortje' dan wel cross-process? En je gaat voorbij aan de vraag over de hoeveelheid code

Semaphores zijn op aanvraag cross-process, de hoeveelheid code die dat oplevert is ook zo'n 4 á 5 regels code per process (inclusief shared memory).

En nu jij in net zoveel code, en net zo waterdicht gesynchroniseerd

Welke syncing, hoe unlock je die mutex?

[curry684]

Verwijderd schreef op 04 juni 2004 @ 10:25:
[...]


Semaphores zijn op aanvraag cross-process, de hoeveelheid code die dat oplevert is ook zo'n 4 á 5 regels code per process (inclusief shared memory).

Wist ik niet (every day something new ), maar dat gaat dan dus niet via pthreads... ergo je moet meerdere API's opentrekken. En een semaphore kun je niet fatsoenlijk als event gebruiken

Welke syncing, hoe unlock je die mutex?

Uh ja, in korte voorbeeldcode ter demonstratie ga ik ervan uit dat mensen zelf de benodigde call naar ReleaseMutex wel in kunnen vullen

[MSalters]

Bij de boost mailinglist steekt er om de zoveel tijd weer de discussie op over POSIX thread cancellation. Afgezien van een persoon is de unanieme opinie dat die dingen niet in C++ passen, en de kans dat er iets dergelijks in C++0x komt is dus te verwaarlozen. Dus

conditions hangen niet aan een mutex omdat dat problemen kan opleveren met cancelpoints i.s.m. cleanup-handlers.

is voor een heleboel mensen nog een bevestiging dat pthreads niet in een OO-omgeving thuishoren.

[Verwijderd]

MSalters schreef op 04 juni 2004 @ 16:55:
Bij de boost mailinglist steekt er om de zoveel tijd weer de discussie op over POSIX thread cancellation. Afgezien van een persoon is de unanieme opinie dat die dingen niet in C++ passen, en de kans dat er iets dergelijks in C++0x komt is dus te verwaarlozen. Dus
[...]
is voor een heleboel mensen nog een bevestiging dat pthreads niet in een OO-omgeving thuishoren.

Ik vind dit een bijzonder slap argument, C++ is meer dan een OO taal, dus als bepaalde constructies niet in een OO concept passen betekent dat nog niet dat ze onacceptabel voor C++ zijn. Thread cancellation op zich is een geweldig concept als het safe kan.

Het punt met thread_cleanup_xxx is dat er extensies nodig zijn zodat een pthread_cleanup_push-achtig iets kan worden ingebouw in een constructor en een pthread_cleanup_pop-achtig iets in een destructor; de meeste implementaties leveren die extensies en er wordt zwaar gelobbyd om ze opgenomen te krijgen in de standaard.

[curry684]

Nou nee, thread cancellation is een stupide concept voor mensen die geen clean shutdown routines kunnen schrijven

[Verwijderd]

Wat is dan een goeie (multi-platform) thread library?

overigns: de problemen lagen aan de STL die niet thread safe is

[MSalters]

Verwijderd schreef op 04 juni 2004 @ 17:33:
[...]
Ik vind dit een bijzonder slap argument, C++ is meer dan een OO taal, dus als bepaalde constructies niet in een OO concept passen betekent dat nog niet dat ze onacceptabel voor C++ zijn. Thread cancellation op zich is een geweldig concept als het safe kan.

Ik zal het anders formuleren: Het past niet in C++'s object model. Met generic programming gaat het inderdaad ook fout, zo mogelijk nog harder. Juist in een template is het onacceptabel als er andere threads opeens gaan zieken in template code.

Het punt met thread_cleanup_xxx is dat er extensies nodig zijn zodat een pthread_cleanup_push-achtig iets kan worden ingebouw in een constructor en een pthread_cleanup_pop-achtig iets in een destructor; de meeste implementaties leveren die extensies en er wordt zwaar gelobbyd om ze opgenomen te krijgen in de standaard.

Zwaar gelobbyed? Ik heb er nog nooit iets serieus over gehoord, en ik krijg alle C++ papers via NEN/NNI. En als er iemand echt serieus wil lobbyen, dan weten ze mij ook direct te vinden. Voor zover ik weet is alleen Alexander Terekhov _{(geloof dat het zo gespeld wordt, de combinatie POSIX+A.T. gaat bij mij ongelezen in de prullenbak)} hier mee bezig. Hij is geen ISO-lid, geen implementor, en zijn lobby-skills zijn nihil.

[Verwijderd]

MSalters schreef op 05 juni 2004 @ 16:25:
Ik zal het anders formuleren: Het past niet in C++'s object model. Met generic programming gaat het inderdaad ook fout, zo mogelijk nog harder. Juist in een template is het onacceptabel als er andere threads opeens gaan zieken in template code.

Hoezoe gaat het in generic programming meer fout dan in rechttoe rechtaan C-style? Cancellation betekent simpelweg dat een non-actieve thread (die op sync wacht die wellicht nooit komen gaat) beëindigd kan worden. Als er een methode is om die thread dan niet simpelweg te aborten maar zijn resources te laten opruimen, wat is daar dan fundamenteel op tegen?