🚀 go-pugleaf

Benjamin Teugels wrote:
> 
> Hey,
> 
> Ik zit met een raar probleem eigenlijk.  Ik heb hier een klein
> testprogrammaatje gemaakt dat gebruikt maakt van de POSIX Threads.
> 
> Dit programma loopt in een oneindige lus waarin hij telkens om de vijf
> seconden tien threads aanmaakt.  Geen nood, dit is opzettellijk gedaan. :-)
> 
> Als de threads worden aangemaakt, krijgen ze als argument de functie
> (function) mee, waarmee de thread moet starten, en een pointer naar een
> object (zijnde het argument van de functie) in dit geval een structure met
> enkel een array van 4K characters.
> 
> Nu, om het gebruikte geheugen van het object vrij te geven waar de pointer
> naar verwijst, _moet_ je dit doen in de functie zelf, vermits je ni weet
> wanneer de functie/thread zal eindigen.  Daarmee doe ik dit ook in mijn code
> met de statements "delete my_structure; my_structure = NULL".  Dit staat op
> zowat elke site op het net die handelt over POSIX threads.  Als je dit
> programma echter effe laat lopen onder Linux/BSD, zie je als je het proces
> in het oog houdt dat het geheugen constant blijft stijgen met exact 10 x 4K
> om de 5 seconden...
> 
> Onder Linux staan er altijd 2 processen van dit programma in de lijst, onder
> OpenBSD maar eentje.  Doch is het geheugengedrag op beide systemen
> hetzelfde, het blijft steeds meer geheugen innemen.
> 
> Nu is mijn vraag, is dit normaal?
> 

In uw code garandeert niets dat uw threads ooit zullen gescheduled
worden, of ooit zullen finishen. Dat zal wel het probleem zijn: je
alloceert geheugen, je creeert de thread, maar je niets garandeert dat
die ooit uitgevoerd wordt. Vertrouw NOOIT op een willekeurige delay (bv
10ms, of zelfs 5 seconden) om ervan uit te gaan dat een bepaalde thread
'nu toch wel al geactiveerd zou moeten zijn'. Waarschijnlijk staan die
ergens gescheduled en lui te wachten tot ze goesting hebben om te
runnen. Probeer eens print statements toe te voegen in je code wanneer
je alloceert en vrijgeeft, en controleer of die evenveel voorkomen.

Hoe je dit oplost is left as an exercise to the reader, en highly
application afhankelijk. De oplossing zit hem natuurlijk in het gebruik
van synchronisatiemethoden. Een voorbeeld kan, op aanvraag.

Groetjes,
Wim.