5

Stavo cercando di leggere l'implementazione di Synchronous Queue
Non è così semplice per me. Sembra che stia usando una lista collegata in cui ogni nodo è associato a una discussione.
E la parte principale utilizza un ciclo di rotazione in attesa di attività da inserire nella coda.
Mi chiedevo perché viene utilizzato un ciclo di spin invece di qualcosa come wait/notify?
Ora in questo modo uno dei core è andato a causa di questo ciclo di rotazione costante, giusto?
Sto cercando di capire questo punto e ottenere una conoscenza approssimativa della progettazione del sincrono codaCercando di capire i meccanismi di una coda sincrona

UPDATE
Ciò che mi ha anche preoccupante è come i fili cameriere start/stop.

+0

Questa è la base degli algoritmi lock-free - si noti che la rotazione viene eseguita solo quando c'è qualcosa da trasferire. trasferimento è fatto o se non c'è niente da fare, il metodo restituisce. – assylias

+0

@assylias: Nella maggior parte delle parti di "TransferQueue.transferer' c'è un' continue' non un 'return'. C'è un ritorno in alcuni casi in cui caso non ho idea di cosa succede ai camerieri e quando/come si riavviano – Jim

risposta

4

Il punto del numero SynchronousQueue consiste nel sincronizzare qualcosa che di solito è abbastanza asincrono: un thread inserisce un elemento nella coda mentre un altro tenta di prelevarlo.

Lo SynchronousQueue non è in realtà una coda. Non ha capacità, non ha memoria interna. Permette solo di prelevare dalla coda quando un altro processo sta tentando di mettere in coda.

Esempio:

processo A cerca di mettere in coda. Questo blocca per ora. Il processo B tenta di prelevare dalla coda. Poiché qualcuno sta provando a mettere, l'oggetto viene trasferito da A a B, ed entrambi sono sbloccati.

Il processo B tenta di prendere dalla coda, ma nessuno tenta di mettere. Quindi B è ora bloccato. Il processo A ora vuole mettere un oggetto. Ora l'oggetto viene trasferito su B e A e B non sono più bloccati.

Circa il blocco:

L'implementazione Sun/Oracle JRE fa uso di polling invece di un wait/notify modello se si fa un funzionamento temporizzato (come "cercare di prendere per 1 secondo"). Questo ha senso: riprova periodicamente fino a quando il tempo è scaduto. Quando esegui un'operazione non temporizzata (come "prendi, non importa quanto tempo ci vuole" usa park, che si risveglia se la situazione è cambiata.) In nessuna delle due situazioni uno dei tuoi core sarà costantemente occupato a girare un ciclo. for (;;) significa "retry indefinately" in questo caso, non significa "rotazione costante"

+0

Penso che non ci sia alcun blocco effettivo. Voglio dire che la parte di blocco è implementata tramite un ciclo di spin. Questo ciclo "mangia" cicli di CPU. Perché il blocco non è stato implementato tramite una qualche forma di 'wait' o' sleep'? – Jim

+0

Pensi male, quindi ;-) C'è un blocco. Ecco perché l'API doc che hai collegato si apre con la frase '" Una coda di blocco in cui ogni operazione di inserimento deve attendere un'operazione di rimozione corrispondente da un altro thread, e viceversa. "' –

+1

Ma stai citando la javadoc.I ho già menzionato che ho cercato di capire l'implementazione in cui ho trovato 'for (;;) {' nell'implementazione di 'transfer'. – Jim

Problemi correlati