Ho 6 fili. Uno dei thread entra in uno scope e attiva il 'lock' e tutti gli altri thread sono in attesa e vogliono entrare nello stesso scope."Lock" richiede tempo CPU?
Ora, gli altri thread avranno tempo CPU? L'altro thread si trova nella pianificazione del thread? Capisco che tutti gli altri thread siano in stato di attesa - ma la CPU proverà a continuare il thread e cercherà di entrare nel campo di applicazione (anche se l'ambito non è accessibile)
Quando provi ad inserire un blocco che è già preso, filetti prima spinlock per un po 'e infine sospendi e inserisci uno stato di attesa.
Ancora bruciano il tempo della CPU mentre girano, ma non più una volta che aspettano.
Espandere un po ': lo spinwait è fatto perché è più economico di una transizione del kernel e quindi ottimizza il caso in cui il blocco è solo leggermente conteso. – Richard
cos'è lo spinlock? puoi rispondere in 1 frase? –
@Royi Il thread continua a controllare se l'aspetto è libero in un ciclo. Qualcosa come 'while (! Lock.TryEnter()) {}' Masterizza CPU, ma evita il sovraccarico di una transizione del kernel e la programmazione dei thread. Va bene se il blocco diventa presto disponibile, ma è brutto se richiede più tempo. Questo è il motivo per cui si bloccano gli spinlock per un po 'e poi si attende. – CodesInChaos
Non è così che funziona la serratura. Non darai a nessuno più "tempo di CPU". Se stai bloccando potresti introdurre periodi di attesa e potenzialmente deadlock in cui i thread sono in attesa l'uno dell'altro.
La mia comprensione è che gli altri thread riceveranno ancora timeslices, che useranno per verificare lo stato del blocco. Se il lucchetto è ancora sul posto, torneranno a dormire, altrimenti procederanno. – xbonez
questo è quello che ho capito anche io - ma questo richiede tempo alla CPU ... quindi questo è un po 'occupato - e questo è molto brutto. – Yanshof