[BCB] WaitForSingleObject onwillekeurig

[Verwijderd]

Voorbordurend op Topic van IJnte ben ik bezig met Threads en met behulp van een Mutex wil ik er voor zorgen dat de verschillende Threads weten wanneer ze mogen schrijven. Als test programma is het volgende gemaakt

C++:

for(int a=0; a<=6;a++)

{
 ListBox1->Items->Clear();
 MyThread[a]= new MyText(false);
}

C++:

 for(int q=1; q<=2;q++)
 {
  WaitForSingleObject(Form1->hMutex,INFINITE);
  Form1->ListBox1->Items->Add(ThreadID);
  ReleaseMutex(Form1->hMutex);
 }

Aan de listbox kan ik zien wanneer een Thread het recht heeft gekregen om te schrijven in een Listbox. Maar wat blijkt is dat het wachten op de mutex geen queue kent en dus onwillekeurig weer mutex afgeeft. Voorbeeld :
788,788,484,484,1424,1424,1772,1772,1596,260,1596,908,260,908


Dit is onwenselijk omdat ik er wil voor zorgen dat de processen elkaar goed opvolgen. Want anders maakt die eerst één thread af voordat die aan een andere begint.

Hoe kan ik dit oplossen op een simpele manier?

[ Voor 3% gewijzigd door Verwijderd op 14-01-2005 12:51 ]

[MSalters]

Als je met threads gaat werken kun je beter eerst een goed boek erover lezen. Wat jij wil staat haaks op het doel van threads. Het doel is dat je dingen tegelijk kunt doen, en jij dwingt ze juist in een vaste volgorde. Het werk wat jij door 6 threads laat doen kan dus beter door een enkele thread worden gedaan, dan heb je niet eens de overhead van het geklooi met mutexen.

[Verwijderd]

Ik snap de bedoeling wel van threads maar het is de bedoeling dat er dadelijk 7 threads opstarten voor zeven verschillende apparaten, er worden dan los van elkaar instellingen gemaakt. Maar ze moeten dadelijk wel over een scsi bus schrijven.

Dus als test programma heb ik het bovenstaande voorbeeld gemaakt om te kijken of een mutex een queue heeft, dat wil zeggen dat degene die al het langste wacht de eerste kans krijgt om de mutex te bemachtigen.

Hoe kan ik zo'n queue maken of regelen, iemand ideeen?

[H!GHGuY]

je maakt 1 klasse aan die de queue beheert
en dan moet die telkens de thread die opgestart moet worden opstarten en wachten tot ie klaar is.

of simpeler: 1 thread met een queue die telkens de functieaanroep binnen zichzelf(thread) doet.
heb je maar 1 thread nodig voor alle werk

maar of dit een goeie oplossing is... dunno. hangt ervan af wat ej wil bereiken

[ Voor 15% gewijzigd door H!GHGuY op 15-01-2005 11:38 ]

[curry684]

MSalters schreef op vrijdag 14 januari 2005 @ 13:27:
Als je met threads gaat werken kun je beter eerst een goed boek erover lezen. Wat jij wil staat haaks op het doel van threads. Het doel is dat je dingen tegelijk kunt doen, en jij dwingt ze juist in een vaste volgorde. Het werk wat jij door 6 threads laat doen kan dus beter door een enkele thread worden gedaan, dan heb je niet eens de overhead van het geklooi met mutexen.

Eventueel kun je het als 'chained worker threads' aanpakken, dat je 1 thread start die het werk doet, en dan voordat die klaar is een nieuwe thread voor part 2 start and so on