Questa domanda è ispirata a this other question.Java: in attesa sul blocco sincronizzato, chi va per primo?
Se più thread sono in attesa su un blocco synchronized e il blocco diventa disponibile, chi va per primo? È per priorità del thread (e quindi first-come-first-served)?
E si applicano le stesse regole per notify (con più thread wait)?
Secondo questo ragazzo: http://tutorials.jenkov.com/java-concurrency/starvation-and-fairness.html
Java rilascia nessuna garanzia sulla sequenza. Quindi suppongo che non sia basato sulla priorità del thread
Proverò a cercare ulteriormente una spiegazione su come Java decida effettivamente chi deve iniziare.
+1 Interessante. Risulta che i blocchi nel pacchetto di concorrenza hanno una modalità di equità opzionale, nel qual caso funzionano a fifo. In caso contrario, è arbitrario. Avrei pensato che la priorità del thread avrebbe dovuto avere un ruolo qui. – Thilo
Sono d'accordo che sarebbe stata la scelta "naturale". –
L'equità ha un costo e la prevedibilità viene raggiunta a scapito della grande perdita di throughput. Inoltre, il requisito di equità impedirebbe le tonnellate di ottimizzazioni che VM potrebbe fare nell'implementare acquisizioni di blocco (cose come spin-spin sottili, ecc.). – sjlee
riguarda la seconda domanda
uno di loro viene scelto per essere risvegliato. La scelta è arbitraria e avviene a discrezione dell'implementazione. Un thread attende sul monitor di un oggetto chiamando uno dei metodi di attesa.
Da http://download.oracle.com/javase/1.4.2/docs/api/java/lang/Object.html#notify()
Qualche idea su come funziona Hotspot? – Thilo
Se prendo queste due risposte insieme alle priorità di Thread non risultanti nelle priorità del thread OS su Linux (almeno nella maggior parte delle situazioni), quelle priorità non sembrano fare molto ... – Thilo
@Thilo Dipende dall'implementazione. Non posso dire che dipende dal sistema operativo. –
Dipende dalla priorità della filettatura e dall'algoritmo di schedatura del thread e anche il blocco sul blocco sincronizzato non è "equo". Ciò significa che se ci sono 2 thread in attesa con la stessa priorità e il primo thread ha atteso più del secondo thread che non significa necessariamente che il primo thread verrà eseguito per primo.
Stai dicendo che la priorità più alta va prima? – Thilo
no scusa, non sto dicendo questo, mi è mancato quel caso. Sto dicendo che anche un thread con priorità più alta potrebbe essere eseguito dopo un thread con priorità inferiore a causa della correttezza. Questo perché il blocco ingiusto fornisce garanzie di vivacità più deboli che richiedono che tutte le discussioni finiscano per acquisire il lucchetto. – punkers
Qualcun altro ha menzionato la disponibilità di serrature da fiera. Se ti interessa davvero chi va per primo, allora potresti avere un problema in tempo reale. In tal caso, è possibile utilizzare RTSJ, in cui è specificato l'ordine e l'altra semantica dell'acquisizione del blocco. Le specifiche sono disponibili nello RTSJ Spec in Sincronizzazione. Citando dalla sezione logica:
norme del codice Java per sincronizzato forniscono un mezzo per mutua esclusione ma non impediscono prioritari illimitata inversioni e quindi sono insufficienti per applicazioni in tempo reale. Questa specifica rafforza i semantica per codice sincronizzato di di mandato controllo inversione di priorità, in particolare fornendo classi per l'ereditarietà priorità e la priorità emulazione soffitto. L'ereditarietà di priorità è più ampiamente implementata in sistemi operativi in tempo reale e è quindi richiesto ed è il meccanismo di default predefinito in questa specifica .
Se i "lucchetti chiari" sono ciò che si sta cercando, esaminare il pacchetto java.util.concurrent. Ad esempio, ReEntrantLocks è giusto. L'equità deriva dal fatto che la priorità è data ai thread di attesa più lunghi, analoghi al concetto di "Aging" nella pianificazione dei processi. – questzen