Ik heb me altijd afgevraagd wat ze zijn: elke keer als ik erover hoor, gaan beelden van futuristische vliegwielachtige apparaten door mijn hoofd dansen (rollen?)…
Wat zijn dat?
Antwoord 1, autoriteit 100%
Als je gewone vergrendelingen gebruikt (mutexen, kritieke secties, enz.), zet het besturingssysteem je thread in de WAIT-status en voorkomthet door andere threads op dezelfde core te plannen. Dit heeft een prestatiestraf als de wachttijd erg kort is, omdat je thread nu moet wachten op een preëmptie om weer CPU-tijd te ontvangen.
Bovendien zijn kernelobjecten niet in elke staat van de kernel beschikbaar, zoals in een interrupt-handler of wanneer paging niet beschikbaar is, enz.
Spinlocks veroorzaken geen voorkoop, maar wachten in een lus (“spin”) totdat de andere kern het slot vrijgeeft. Dit voorkomt dat de thread zijn kwantumverliest en verdergaat zodra de vergrendeling wordt vrijgelaten. Het eenvoudige mechanisme van spinlocks stelt een kernel in staat om het in bijna elke staat te gebruiken.
Daarom is een spinlock op een machine met één kern gewoon een “disable interrupts” of “raise IRQL” waardoor threadplanning volledig wordt voorkomen.
Spinlocks zorgen er uiteindelijk voor dat kernels “Big Kernel Lock”s (een vergrendeling die wordt verkregen wanneer de kern de kernel binnengaat en bij de uitgang wordt vrijgegeven) en granulaire vergrendeling over kernelprimitieven hebben, wat leidt tot betere multi-verwerking op multi-core machines en dus betere prestaties .
EDIT: Er kwam een vraag: “Betekent dit dat ik waar mogelijk spinlocks moet gebruiken?” en ik zal proberen het te beantwoorden:
Zoals ik al zei, zijn Spinlocks alleen nuttig op plaatsen waar de verwachte wachttijd korter is dan een kwantum (lees: milliseconden) en preëmptief gebruik niet veel zin heeft (er zijn bijvoorbeeld geen kernelobjecten beschikbaar).
Als de wachttijd onbekend is, of als je in de gebruikersmodus bent, zijn Spinlocks niet efficiënt. Je verbruikt 100% CPU-tijd op de wachtende core terwijl je controleert of er een spinlock beschikbaar is. Je voorkomt dat andere threads op die kern draaien totdat je kwantum verloopt. Dit scenario is alleen haalbaar voor korte bursts op kernelniveau en onwaarschijnlijk een optie voor een gebruikersmodustoepassing.
Hier is een vraag over SO waarin wordt ingegaan op: Spinlocks, hoe nuttig zijn ze?
Antwoord 2, autoriteit 21%
Stel dat een bron wordt beschermd door een slot, een thread die toegang tot de bron wil, moet eerst het slot verkrijgen. Als het slot niet beschikbaar is, kan de thread herhaaldelijk controleren of het slot is vrijgegeven. Gedurende deze tijd wacht de thread bezig, controlerend op het slot, CPU gebruikend, maar geen nuttig werk doend. Zo’n slot wordt een spinslot genoemd.
Antwoord 3, autoriteit 14%
Het is eigenlijk een lus die doorgaat totdat aan een bepaalde voorwaarde is voldaan:
while(cantGoOn) {};
Antwoord 4, autoriteit 5%
while(something != TRUE ){};
// it happend
move_on();
Antwoord 5, autoriteit 3%
Het is een type slot dat druk bezig is met wachten
Het wordt beschouwd als een anti-patroon, behalve voor zeer lage driverprogrammering (waar het kan gebeuren dat het oproepen van een “juiste” wachtfunctie meer overhead heeft dan gewoon een paar cycli bezig te zijn met vergrendelen).
Zie bijvoorbeeld Spinlocks in Linux-kernel.
Antwoord 6, autoriteit 2%
SpinLocks zijn degenen waarin de thread wacht tot het slot beschikbaar is. Dit wordt normaal gesproken gebruikt om overhead bij het verkrijgen van de kernelobjecten te voorkomen wanneer het binnen een korte tijdspanne mogelijk is om het kernelobject te verwerven.
Bijvoorbeeld:
While(SpinCount-- && Kernel Object is not free)
{}
try acquiring Kernel object
Antwoord 7, autoriteit 2%
U zou een spinlock willen gebruiken als u denkt dat het goedkoper is om een drukke wachtlus in te gaan en een resource te poolen in plaats van te blokkeren wanneer de resource is vergrendeld.
Spinnen kan nuttig zijn wanneer vergrendelingen fijnkorrelig en groot in aantal zijn (bijvoorbeeld een vergrendeling per knooppunt in een gekoppelde lijst) en wanneer de vergrendelingstijden altijd extreem kort zijn. Over het algemeen moet men, terwijl men een spin-lock vasthoudt, vermijden om te blokkeren, alles aan te roepen wat zelf kan blokkeren, meer dan één spin-lock tegelijk vast te houden, dynamisch verzonden oproepen te doen (interface en virtuals), statisch verzonden oproepen te doen in elke code die men niet doet’ geen geheugen bezitten of toewijzen.
Het is ook belangrijk op te merken dat SpinLock een waardetype is, om prestatieredenen. Als zodanig moet men heel voorzichtig zijn om niet per ongeluk een SpinLock-instantie te kopiëren, omdat de twee instanties (het origineel en de kopie) dan volledig onafhankelijk van elkaar zouden zijn, wat waarschijnlijk zou leiden tot foutief gedrag van de toepassing. Als een SpinLock-instantie moet worden doorgegeven, moet deze worden doorgegeven door middel van referentie in plaats van door waarde.
Antwoord 8
In een notendop, spinlock gebruikt atomaire vergelijking en swap (CAS) of test-en-set-achtige instructies om lock-free, wait-free thread-veilige idioom te implementeren. Dergelijke structuren schalen goed in multi-core machines.
Antwoord 9
Nou, ja – het punt van spin-locks (vs een traditionele kritieke sectie, enz.) is dat ze onder bepaalde omstandigheden betere prestaties bieden (multicore-systemen …), omdat ze niet meteen de rest van het kwantum van de thread opleveren .
Antwoord 10
Spinlock, is een type slot dat niet kan worden geblokkeerd & niet in slaap kunnen vallen. Elke thread die een spinlock voor een gedeelde of kritieke bron wil verkrijgen, zal continu draaien, waardoor de CPU-verwerkingscyclus wordt verspild totdat deze de vergrendeling voor de gespecificeerde bron verwerft. Zodra spinlock is verkregen, probeert het het werk in zijn kwantum te voltooien en vervolgens respectievelijk de bron vrij te geven. Spinlock is het type slot met de hoogste prioriteit, je kunt eenvoudig zeggen dat het een niet-preventief soort slot is.
Antwoord 11
Het is een lus die ronddraait totdat aan een voorwaarde is voldaan.