Wat is een threadpool?

Een thread pool is een groep van vooraf geïnstantieerde, inactieve threads die klaar staan om werk te krijgen. Deze hebben de voorkeur boven het instantiëren van nieuwe threads voor elke taak wanneer er een groot aantal korte taken moet worden uitgevoerd in plaats van een klein aantal lange. Dit voorkomt dat u de overhead moet oplopen van het een groot aantal keren maken van een thread.

Implementatie varieert per omgeving, maar vereenvoudigd heeft u het volgende nodig:

• Een manier om threads te maken en ze in een inactieve staat te houden. Dit kan worden bereikt door elke thread bij een barrière te laten wachten totdat het zwembad het aan het werk is. (Dit kan worden gedaan met mutexes ook.)
• Een container om de gemaakte threads op te slaan, zoals een wachtrij of een andere structuur die een manier heeft om een thread aan de pool toe te voegen en eruit te halen.
• Een standaardinterface of abstracte klasse voor de threads om te gebruiken bij het doen van werk. Dit kan een abstracte klasse zijn met de naam Task met een execute() -methode die het werk doet en vervolgens terugkeert.

Wanneer de threadpool is aangemaakt, zal deze ofwel een bepaald aantal threads instantiëren om beschikbaar te maken of nieuwe aanmaken, afhankelijk van de behoeften van de implementatie.

Wanneer de pool wordt overhandigd een Task, het neemt een thread uit de container (of wacht tot er een beschikbaar komt als de container leeg is), geeft het een Task, en ontmoet de barrière. Dit zorgt ervoor dat de inactieve thread de uitvoering hervat, waarbij de execute() -methode van de Task wordt aangeroepen. Zodra de uitvoering is voltooid, geeft de draad zichzelf terug aan het zwembad om in de container te worden gedaan voor hergebruik en ontmoet dan de barrière, waarbij hij zichzelf in slaap brengt totdat de cyclus zich herhaalt.

Opmerkingen

• Een threadpool is een groep vooraf geïnstantieerde, inactieve threads die klaar staan om werk te krijgen. […] Dit voorkomt dat u de overhead moet oplopen van het een groot aantal keren maken van een thread. – dit zou door Google moeten worden uitgespuugd wanneer iemand zoekt naar ” thread pool ”
• Heeft het maken van threadpool een interne barrière? Kunt u op deze regels een referentie delen?
• @overexchange Nee, dat is niet zo. Mijn verwijzing naar deze vraag was als voorbeeld van een betere manier om uw barrièrevraag opnieuw te schrijven. (Als je dat doet, zal ik een antwoord schrijven.)
• een van de beste korte antwoorden.

Threadpool is een verzameling beheerde threads die gewoonlijk in een wachtrij zijn georganiseerd, die de taken in de takenwachtrij uitvoeren.

Het is duur om elke keer dat u iets asynchroon moet uitvoeren een nieuw thread-object te maken. In een threadpool voegt u de taken die u asynchroon wilt laten uitvoeren toe aan de takenwachtrij en de threadpool zorgt ervoor dat een eventuele beschikbare thread wordt toegewezen aan de bijbehorende taak. Zodra de taak is voltooid, vraagt de nu beschikbare thread om een andere taak (ervan uitgaande dat er nog wat over is).

Threadpool helpt je te voorkomen dat je meer threads maakt of vernietigt dan echt nodig zou zijn.

Ik zou beginnen met het maken van een klas met een wachtrij met threads en een wachtrij met taken. Implementeer vervolgens een methode die een taak aan de takenwachtrij toevoegt en van daaruit verder gaat. Het is duidelijk dat u het ook mogelijk moet maken om het maximum aantal toegestane threads in een threadpool in te stellen.

Voorbeeld uit het echte leven;

1. Faciliteit: besturingssysteem
2. Secties: toepassingen
3. Mensen: discussies

Je hebt daar een faciliteit 12 mensen werken. Er zijn 3 secties van deze faciliteit. Keuken, toiletten en beveiliging. Als je geen thread pool-techniek gebruikt, is dat hoe het werkt: alle 12 mensen staan in een vergaderruimte, als nieuwe klanten langs de faciliteit komen en om taken vragen, dan scheid je de mensen in groepen en stuur je ze om te doen hun werk en komen terug naar de vergaderruimte. Maar voordat ze naar hun taak gaan, is er een voorbereidingsfase. Ze moeten een correct uniform dragen, bepaalde apparaten uitrusten en naar dat gedeelte lopen, het werk afmaken en terugkomen. elke keer dat ze hun taak afmaken (thread eindigt), moeten ze teruglopen naar de vergaderruimte, hun uniform uitkleden, apparatuur uittrekken en wachten op de volgende job. Deze verwijzen naar het creëren van threadcontext, het is geheugentoewijzing en trackinginformatie door OS.Het is te veel tijdrovend voor OS om nieuwe threadbehoeften opnieuw te organiseren.

Als u threadpooling gebruikt, wijst u in de vroege ochtend 6 personen toe aan de keuken, 2 personen aan de toiletruimte en 4 personen voor beveiliging. Ze zullen hun voorbereiding dus maar één keer per dag doen. Zelfs als er geen klanten in de keuken zijn, zullen die 4 mensen aanwezig zijn voor eventuele toekomstige taken. Ze hoeven niet terug te gaan naar de vergaderruimte voordat de keuken sluit (app stopt). Deze 4 mensen zitten in de Kitchen app pool, en zijn klaar om snel te bedienen. Maar je kunt niet beloven dat ze de hele dag aan het werk zijn, aangezien de keuken van tijd tot tijd inactief kan worden. Dezelfde logica geldt ook voor toiletten en beveiliging.

In het eerste scenario verspil je geen thread voor welke taak dan ook, MAAR het kost veel tijd om elke thread voor elke taak voor te bereiden. In de tweede plaats bereid je threads van tevoren voor, dus je kunt niet garanderen dat je alle threads voor alle taken gebruikt, maar OS maakt er meestal geweldige optimalisatie van, zodat je er veilig op kunt vertrouwen.

In toepassingen met meerdere threads is threadpool een “pool van beschikbare threads” die door uw toepassing kan worden gebruikt. Meestal b.v. .NET, het wordt allemaal beheerd, dus u wijst gewoon taken toe en zodra een thread gratis is, gaat deze deze uitvoeren. Dus om een threadpool te implementeren, zou ik verwachten een concept te creëren waarbij taken automatisch worden uitgevoerd door gratis threads zonder expliciete threadcreatie voor elke taak.