"Hallo, Amigo! Ik wil je vertellen over het delen van bronnen. Natuurlijk in verschillende threads.
"Ik blijf praten over de problemen die zich voordoen bij het werken met meerdere threads en hoe deze op te lossen. Dit betekent niet dat het gebruik van threads slecht is. Threads zijn een zeer krachtig hulpmiddel. Sterker nog, ze laten je je programma sneller en gelijkmatiger maken. betrouwbaarder. Hoe complexer een programma is, hoe meer threads en verschillende onafhankelijke onderdelen het heeft."
"Een programma opsplitsen in onafhankelijke (losjes gekoppelde) delen is erg voordelig."
"Stel dat je programma intern is opgedeeld in 100 threads. Maar je hebt alleen een dual-core processor. Dat betekent dat er gemiddeld 50 threads op elke core worden uitgevoerd."
"Als je de prestaties van het programma wilt verbeteren, koop je gewoon een server met twee processors en een paar mooie processors ervoor. Hiermee kun je tot 32 kernen krijgen, wat een prestatieverbetering van 2-20 keer oplevert. Afhankelijk van het aantal van echt onafhankelijke delen waarin het is verdeeld."
"Dit is een van de redenen waarom Java domineert in bedrijfsontwikkeling. Als een bedrijf een complex intern programma heeft dat is geschreven door 20 ontwikkelaars, dan is het veel goedkoper om een andere server te kopen dan om de prestaties van het programma te verdubbelen door middel van optimalisatie."
"Dus daar gaat het allemaal om."
"Maar! Elke keer dat een ontwikkelaar besluit een andere thread te gebruiken, lost hij één probleem op en creëert hij er twee. Meer en meer threads zullen de prestaties van het programma niet eindeloos verbeteren."
"Ten eerste heeft elk programma werk dat niet uit elkaar kan worden gehaald en parallel op verschillende threads kan worden uitgevoerd. Ten tweede worden alle threads op dezelfde processor uitgevoerd. Hoe meer threads je hebt, hoe langzamer ze allemaal werken."
"En, belangrijker nog, threads gebruiken vaak dezelfde objecten (meestal 'shared resources' genoemd)."
"Een thread wil bijvoorbeeld informatie over het voltooide werk opslaan in een bestand. Als er meerdere van dergelijke threads zijn en ze informatie naar hetzelfde bestand willen schrijven, zullen ze elkaar storen. Om te voorkomen dat het bestand een door elkaar gegooide puinhoop, de toegang tot het bestand is beperkt, dwz terwijl één thread het bestand gebruikt, wachten andere."
"Ja, dat weet ik nog. Dat doe je met het gesynchroniseerde trefwoord."
"Precies goed."
"En wat als de threads naar verschillende bestanden schrijven?"
"Formeel zijn dit verschillende objecten, maar ze staan waarschijnlijk op dezelfde harde schijf."
"Dus, is het echt mogelijk om iets in de processor te parallelliseren?"
"Technisch gezien wel, maar zodra je thread iets nodig heeft naast de gegevens die het heeft, kan dat iets al bezet zijn door een andere thread - en zal je thread moeten wachten."
"Nou, wat moet ik dan doen? Hoe weet ik of ik veel draden moet maken of niet?"
"Dit wordt direct bepaald door de architectuur van je programma. Elk project heeft zijn eigen 'architect' die alle 'bronnen' kent die in het programma worden gebruikt, hun beperkingen kent en hoe goed/slecht ze parallel zijn."
"En als ik het niet weet?"
"Er zijn twee opties:"
a) werken onder toezicht van iemand die dat wel doet
b) krijg wat klontjes door het zelf uit te zoeken
"Ik ben een robot: ik krijg geen klonten - alleen deuken."
"Nou, pak dan wat deuken."
'Ik begrijp het. Bedankt. Je hebt een aantal dingen verduidelijkt waar ik me al over begon af te vragen.'
GO TO FULL VERSION