[.NET] WaitCallback vs ParametrizedThreadStart

[Verwijderd]

Voor het starten van threads, waarbij je een state object wilt meegeven, dien je gebruik te maken van de ParametrizedThreadStart delegate. Wanneer je met de ThreadPool een background thread wilt starten is echter een WaitCallback delegate nodig met exact dezelfde delegate signature (ThreadPool.QueueUserWorkItem). Iemand een idee waar dit kunstmatige onderscheid op gebaseerd is?

[ Voor 5% gewijzigd door Verwijderd op 05-03-2008 17:12 ]

[Verwijderd]

Wat de method QueueUserWorkItem in feite doet is, zoals de naam zegt, een taak in de wachtrij zetten om uitgevoerd te worden door een thread in de thread pool. Nu is een eigenschap van de thread pool dat er een maximum aantal threads tegelijk actief zijn. Je taak wordt dus uitgevoerd als er een beschikbare thread in de thread pool is. Er wordt dus gewacht tot er een thread vrij is, vandaar dat het een callback is van een wait. Als je daarentegen Thread.Start() gebruikt, wordt de thread direct gestart. Dit is nogal een verschil.

Dat dit op het eerste gezicht hetzelfde resultaat oplevert, namelijk een taak uitvoeren op een thread en een state meegeven, betekent natuurlijk niet dat er gebruik gemaakt moet worden van dezelfde delegate.

[Niemand_Anders]

In je vraagstelling geef je eigenlijk zelf al het antwoord. Een ThreadPool start een background thread en *ThreadStart start direct thread. Dat is het feitelijke onderscheid tussen de ThreadPool en de thread. Zoals Negerzoen aangeeft wacht de ThreadPool totdat er een thread beschikbaar is en roept dan jouw callback aan.

En alle instructies welke jezelf niet direct start worden geregeld met callbacks. BeginReceive is een directe aanroep, terwijl EndReceive met een callback werkt.

[whoami]

Volgens mij is de vraag van vieux anders:
Volgens mij vraagt hij zich -en ik ondertussen ook een beetje- af waarom er beslist werd om hiervoor 2 aparte delegates te voorzien, nl de ParametrizedThreadStart delegate en de WaitCallback delegate.
Het enige waar ik kan aan denken, is gewoon om geen verwarring te veroorzaken, en idd aan te geven dat het starten van een thread via de ThreadPool (enqueuen) idd anders is dan een thread direct te starten.

[Verwijderd]

whoami schreef op donderdag 06 maart 2008 @ 10:47:
Volgens mij is de vraag van vieux anders:
Volgens mij vraagt hij zich -en ik ondertussen ook een beetje- af waarom er beslist werd om hiervoor 2 aparte delegates te voorzien, nl de ParametrizedThreadStart delegate en de WaitCallback delegate.
Het enige waar ik kan aan denken, is gewoon om geen verwarring te veroorzaken, en idd aan te geven dat het starten van een thread via de ThreadPool (enqueuen) idd anders is dan een thread direct te starten.

Dat is inderdaad wat ik me afvraag; het verschil tussen direct starten en in een queue plaatsen wordt natuurlijk al duidelijk gecommuniceerd via de methode namen: .Start() vs .Queue..()
Maar het zou best goed kunnen dat het de opzet is om dat verschil nog eens extra te benadrukken.