[JAVA] java.util.concurrent.locks

[ragnonerodocet]

Sul sito della sun, nella definizione dell'interfaccia Lock, ho trovato questa definizione che mi ha un po' spiazzato...

con synchronized, quando più lock sono acquisiti, devono essere rilasciati nell'esatto ordine opposto, e devono essere rilasciati nella stessa "portata lessicale" (lexical scope) nella quale sono stati acquisiti.
L'implementazione di Lock permette invece di acquisire e rilasciare il lock in diversi "scopes" e permette l'acquisizione e il rilascio di lock multipli in qualsiasi ordine.

Qualcuno potrebbe spiegarmi meglio questa differenza?

[andbin]

Originariamente inviato da ragnonerodocet
con synchronized, quando più lock sono acquisiti, devono essere rilasciati nell'esatto ordine opposto, e devono essere rilasciati nella stessa "portata lessicale" (lexical scope) nella quale sono stati acquisiti.
L'implementazione di Lock permette invece di acquisire e rilasciare il lock in diversi "scopes" e permette l'acquisizione e il rilascio di lock multipli in qualsiasi ordine.

Con la parola chiave synchronized, il lock viene acquisito quando si entra nel metodo/blocco synchronized e viene rilasciato quando si esce dal metodo/blocco synchronized. Quindi è ovvio che c'è un ordine ben preciso di acquisizione e rilascio che dipende dall'annidamento delle acquisizioni.

synchronized(oggetto1) {
    synchronized(oggetto2) {
        ...
    }
}

Qui è chiaro che prima acquisisce il lock su oggetto1, poi su oggetto2, quindi terminato il blocco interno rilascia il lock su oggetto2 e terminato il blocco esterno rilascia il lock su oggetto1.

In pratica la sequenza di acquisizione/rilascio dipende dalla struttura del codice, cioè dall'annidamento di blocchi o di invocazioni di metodi. E non può essere altrimenti.

Con i Lock in java.util.concurrent.locks non si ha questo limite, le acquisizioni/rilasci sono fatte invocando appositi metodi sui Lock, quindi si possono fare con sequenze diverse e in contesti diversi.

[ragnonerodocet]

Mamma mia, che ignorante...

Nella mia brada conoscenza del multithreading non avevo pensato che si, pu; esserci solo un thread in esecuzione, ma tale Thread pu; acquisire pi\ lock da oggetti diversi.

Cosa accade se, nell-esempio da Lei fatto, provo con la parola synchronized ad acquisire 2 volte il lock dello stesso oggetto?

public synchronized (this) {
public synchronized(this) {
...
}
}

Errore a runtime di che tipo?

[andbin]

Originariamente inviato da ragnonerodocet
Cosa accade se, nell-esempio da Lei fatto, provo con la parola synchronized ad acquisire 2 volte il lock dello stesso oggetto?

public synchronized (this) {
public synchronized(this) {
...
}
}

Errore a runtime di che tipo?

Nessun errore! Anzi se avessero scelto/stabilito che era una errore, sarebbe stato un gran macello!!!!

Immagina una situazione:

public synchronized void pippo () { ... }

public synchronized void pluto () {
    pippo();
}

Anche qui ci sarebbe l'acquisizione del lock su 'this' annidata 2 volte.

La gestione degli intrinsic lock è reentrant (rientrante). Cioè se un thread cerca di acquisire un lock che già possiede, non ci sono problemi e la acquisizione ha immediatamente successo.
Per il lock vengono mantenuti 2 dati: un contatore e un reference al thread "owner" (proprietario). Se il lock non è di nessuno, il contatore è 0. Se un thread acquisisce il lock, il contatore diventa 1 e viene memorizzato l'owner. Se un thread cerca di acquisire un lock che già possiede, la JVM se ne accorge (il thread è associato al lock) ed incrementa semplicemente il contatore. Ad ogni rilascio il contatore viene decrementato. Questo permette appunto la "rientranza".

E nota che ReentrantLock, lo dice il nome stesso, è pure lui "rientrante".