Van de MSDNis niet echt duidelijk zijn doel.
Kan het worden gebruikt om een intensieve CPU-berekeningstest te simuleren?
Antwoord 1, autoriteit 100%
nee. Het wordt gebruikt als vervanging voor zeer korte slaapoproepen.
Als je multi-threaded locking uitvoert en de bron die je probeert te verwerven al is vergrendeld, ga je meestal slapen en wacht je tot deze vrijkomt. Wanneer u dit doet, geeft u de rest van de tijd die u door de planner was toegewezen op om de processor te gebruiken, zodat iemand anders het kan proberen.
Normaal gesproken is dit prima, vooral voor lange wachttijden, zoals wachten op IO, kunnen tal van andere processen op de CPU worden uitgevoerd terwijl u wacht tot de schijfspil draait.
Soms wacht u echter een korte tijd. In deze gevallen zou je normaal gesproken toch je resterende tijd opgeven en wachten tot alle andere threads hun ding doen voordat je een nieuwe poging doet … dus je kunt vals spelen, in plaats van te wachten, zit je daar voortdurend te peilen in een ‘zijn we bijna daar al?’ manier. Als de vergrendeling slechts een fractie van de resterende tijd wordt vastgehouden, wordt dit een zeer effectief middel om te wachten, het is ook zeer efficiënt omdat de planner zich niet hoeft te bemoeien met het herschikken van alle andere threads om de tijd te gebruiken die u opgeeft als je normaal hebt gewacht.
Het is duidelijk dat als je elke keer draait als je een slot wilt, je niet erg populair zult zijn, je app traag wordt en 100% CPU gebruikt, maar in zeer kleine doses, op het juiste moment, maakt het de app responsiever.
Als je nu denkt ‘wanneer moet ik het gebruiken?’, is dat een lastige beslissing om te maken – als je een bron hebt die heel vaak wordt vergrendeld en heel snel wordt ontgrendeld, dan is een spinlock eromheen in plaats van wachten een goed idee (en test vervolgens uw app op prestaties), als u een korte tijd probeert te draaien en dan terugvalt op normaal wachten, is dat ook een redelijke manier. Maar over het algemeen hoeft u het nooit te gebruiken.
Antwoord 2, autoriteit 71%
Het doel is om “goedkoop” te wachten als u denkt dat de voorwaarde waarop u wacht zeer, zeer binnenkortzal uitkomen. Normaal gesproken, als je ergens op wacht, laat je de thread in de sluimerstand gaan en zal de processor/het besturingssysteem naar een andere thread schakelen. Context-switches zijn niet bijzonder goedkoop, dus als je geavanceerde kennis van de situatie hebt en denkt dat het goedkoper is om te wachten dan om van context te wisselen, draai je aan wachten.
Mijn advies: als je het moet vragen, hoef je het niet te gebruiken. (Ik heb het zelf nooit gewild.) Eigenlijk is het een van die dingen die in een paar situaties echt nuttig zijn, maar de meeste mensen zouden het goed met rust moeten laten.
Antwoord 3, autoriteit 14%
Als een kanttekening: Microsoft heeft het spinlock-mechanisme van de thread-dispatcher uit Windows 7 verwijderd, omdat het niet goed schaalde voor multicore-CPU’s. Bekijk dit:
Antwoord 4, autoriteit 6%
Wat mij betreft (en ik ben blij met correcties!), is het enige gebruik van spin-wachttijden bij het implementeren van een vergrendelings- of inter-thread-callback-mechanisme. En geen van beide moet handmatig worden gedaan (meestal), omdat ze al bestaan.
Als je een bron hebt vergrendeld en een andere thread vraagt om gesynchroniseerde toegang, moet deze in principe wachten tot de eerste thread klaar is met het gebruik ervan. Dit wachten kan worden gedaan door simpelweg in een lus te draaien (of anders te slapen + contextwisseling zoals vermeld door Jon).