Segnalazione thread in condizioni di una serratura

Question

ho preso i seguenti punti da questo API e vorrei conoscere la differenza tra i seguenti 2 punti:

1. thread in attesa vengono segnalate in ordine FIFO.

2. L'ordinazione di riacquisizione serratura per fili di ritorno da metodi di attesa è la stessa come per i thread acquisire inizialmente serratura , che è nel caso predefinito non specificato, ma per serrature equi favorisce quei fili che hanno atteso la più lunga.

è legato alla Condition classe che di solito è restituito dal metodo ReentrantLock .newCondition(), e il bit ho citato è spiegare la differenza tra i metodi di Condition ei normali metodi di monitoraggio della classe Object.

"I fili in attesa sono segnalati in ordine FIFO". Penso che finché uno lock viene creato o meno o no, il fatto che i thread in attesa siano segnalati in un ordine FIFO è totalmente irrilevante no? perché comunque è se sono stati costruiti, giusti o meno, che decide come vengono messi in coda.

Basta chiedere una conferma.

Grazie in anticipo.

Answer 1

Vedere di seguito le risposte alle tue domande:

discussioni 1.Waiting sono segnalati in ordine FIFO.

Quando invochiamo il metodo di attesa(), il thread passa allo stato di attesa, l'istruzione sopra riportata indica come vengono segnalati questi thread in stato di attesa. Quindi se i thread T1 passano allo stato di attesa prima di T2, T1 sarà segnalato prima di T2.

2. ordinazione di riacquisizione serratura per fili di ritorno dalla modalità di attesa è la stessa per i thread acquisire inizialmente il blocco, che è nel caso predefinito non specificato, ma per serrature equi favorisce quei fili che hanno atteso la più lunga.

In seguito alla dichiarazione precedente, quando viene segnalato il thread in attesa, esso tende a riacquisire il blocco. Sebbene l'affermazione precedente affermi che T1 sarà segnalato prima di T2, ma quando si tratta di riacquistare il blocco, l'ordine di riacquisizione utilizza concetti definiti da Lock. Quindi, dipende da come è stato creato l'oggetto Lock. Durante la creazione di blocco si potrebbe avere specificato un parametro di equità:

ReentrantLock(boolean fair)

Se sì allora quel parametro viene utilizzato, se non poi di default comportamento di serrature accade, si può leggere di più su ReentrantLock serrature a questo link

Potrebbero esserci ulteriori spiegazioni a queste affermazioni, ho appena provato a descrivere meglio la mia comprensione qui. La speranza è stata in grado di chiarire.

Saluti !!

Answer 2

Fintanto che una serratura viene creata o meno o meno, il fatto che i thread in attesa siano segnalati in un ordine FIFO è totalmente irrilevante, non è vero? Perché comunque è se sono stati costruiti, giusti o meno, che decide come vengono messi in coda.

Penso che sia pertinente.

Considerare uno scenario in cui T1 e T2 sono in attesa di una condizione C (con T1 che aspetta più di T2), T3 è in esecuzione all'interno del monitor e T4 sta aspettando l'acquisizione del blocco iniziale. I segnali T3 C e lascia il monitor rilasciando il blocco. Supponiamo che non si verifichi il wake-up spuria.

Se il blocco è fair, T4 acquisirà definitivamente il blocco prima di T1, ma il fatto che i thread in attesa siano segnalati nell'ordine FIFO garantirà che T1 acquisirà il blocco prima di T2.

Inoltre, se il blocco è non è giusto, non si può dire che filo acquisirà il blocco primo tra T1 e T4, ma ancora il fatto che thread in attesa vengono segnalate FIFO garantisce ordine che T1 acquisterà bloccare prima di T2, a condizione che non si verifichino altri segnali finché T1 non acquisisce il blocco (ad esempio nel caso in cui T1 sia responsabile della successiva segnalazione).

Answer 3

Penso che il codice sorgente possa darci ulteriori indizi su come funziona. ReentrantLock.newCondition() restituisce un ConditionObject in AbstractQueuedSynchronizer .Qui è il collegamento del codice sorgente AQS source code.

1. I thread in attesa sono segnalati in ordine FIFO.

Ci sono due code in AbstractQueuedSynchronizer.

Uno è per l'attesa per il blocco (coda di basta chiamare lo scatto di attesa), vedrete due volatili variabile testa e coda nella definizione di classe AbstractQueuedSynchronizer s', e il parametro di equità influenzerà questo behavior.When della coda Sei nuovo una fiera ReentrantLock e chiamare acquisiscono, AQS chiamerà FairSync s' tryAcquire per controllare se thread corrente è il primo thread in attesa nella serratura coda in attesa, vedi hasQueuedPredecessors.

un'altra coda è la coda del segnale nella definizione di ConditionObject, vedrete due variabili firstWaiter e lastWaiter .Quando attendono si chiama, un nodo aggiungerà alla coda della coda e quando viene chiamato il segnale, un nodo dalla testina verrà rimosso dalla coda e aggiunto alla coda di attesa del blocco per riacquisire il blocco. Aggiungere alla coda di attesa blocco non significa che verrà svegliato, ma un blocco .unlock() verrà chiamato dopo il segnale , che attiverà i camerieri, vedere unparkSuccessor.

2. ordinazione di riacquisizione serratura per fili di ritorno dalla modalità di attesa è la stessa per i thread acquisire inizialmente il blocco, che è nel caso predefinito non specificato, ma per serrature equi favorisce quei fili che hanno atteso la più lunga.

svegliarsi dal attendono metodo non intendeva tenere il blocco, si chiamerà acquireQueued riacquistare la serratura e potrebbe essere parcheggiate di nuovo. Nella mia comprensione, l'ordine di acquisire inizialmente il blocco è lo stesso che l'ordine di chiamare attendono, così lo stesso come l'ordine di chiamare acquireQueued, cosa confuso me era ma per serrature equo favorisce quei fili che hanno ho aspettato il più lungo, quando svegliarsi dal attendono, a mio parere, sarà il primo thread in coda in attesa di blocco, quando chiamata acquireQueued e verificare p == testa & & tryAcquire (arg), bloccare fiera o non ha alcun effetto.

Spero che questo aiuti e lasciami se ho torto.