[JAVA] strategia di sincronizzazione

[mad_hhatter]

ciao ragazzi, ho un problema di sincronizzazione riguardante la seguente situazione.

Ho una sorgente di eventi gestita tramite il pattern Observer per cui tale sorgente comunica con una serie di observer tramite i 2 metodi tagAdded(), tagRemoved().
Ogni observer è un Adapter, nel senso che converte gli eventi in messaggi aventi un dato formato (faccio questo perché è necessario gestire protocolli di comunicazione diversi).
Ogni observer, quindi, è a sua volta un'entità Observable contenente una lista di client (destinatari finali degli eventi emessi dalla sorgente).

Tralasciando la sorgente e sapendo che le invocazione dei metodi tagAdded e tagRemoved sono temporalmente disgiunte, ho il problema di gestire la lista di client finali in uno degli Adapter.
Vorrei evitare di leggere tale lista in mutua esclusione (per ragioni di performance), tuttavia sono in presenza di scrittori multipli (un thread aggiunge client, un altro rileva i client "morti" e li rimuove). Quindi non posso adottare la tecnica "copy on write".

Se qualcuno avesse la pazienza di dare un'occhiata al codice che ho postato, vorrei discutere la strategia da me utilizzata.
Grazie infinite




public class Main implements RfidListener, Runnable {

private ArrayList<Socket> listeners = new ArrayList<Socket>();
private ServerSocket s;

public Main(int port) throws IOException {
s = new ServerSocket(port);
}

public void run() {
while (true) {
try {
Socket client = s.accept();
addRemoteClient(client);
} catch (IOException e) {}
}
}

@Override
public void tagAdded(RfidTag tag) {
System.out.println("added " + tag.getRFID());
String xmlString = "<rfidItem status=\"added\" id=\""
+ tag.getRFID() + "\"></rfidItem>" + '\0';
sendXmlMessage(xmlString);
}

@Override
public void tagRemoved(RfidTag tag) {
System.out.println("removed " + tag.getRFID());
String xmlString = "<rfidItem status=\"removed\" id=\""
+ tag.getRFID() + "\"></rfidItem>" + '\0';
sendXmlMessage(xmlString);
}

private void addRemoteClient(Socket client) {
synchronized (this) {
if (client == null) {
return;
}
if (!listeners.contains(client)) {
listeners.add(client);
}
}
}

private void deleteRemoteClient(Socket client) {
synchronized (this) {
listeners.remove(client);
}
}

/*
* snapshot viene usato solo da sendXmlMessage()
* e serve a risparmiare allocazioni nell'esecuzione
* di listeners.toArray(). Questa strategia funziona
* solo se le invocazioni di tagAdded(), tagRemoved()
* sono temporalmente disgiunte. Inoltre questa
* strategia ha senso solo se la probabilità che il
* numero di elementi in listeners superi la dimensione
* corrente di snapshot è bassa.
*/
private Socket[] snapshot = new Socket[100];
private void sendXmlMessage(String xmlString) {
if (xmlString == null) {
return;
}
byte[] message = xmlString.getBytes();
synchronized (this) {
snapshot = listeners.toArray(snapshot);
}
for (int i = 0; i < snapshot.length; i++) {
if (snapshot[i] == null) {
break;
}
try {
snapshot[i].getOutputStream().write(message);
} catch (IOException e) {
try {
snapshot[i].close();
} catch (IOException e1) {}

deleteRemoteClient(snapshot[i]);
}
}
}

}

[^TiGeRShArK^]

mmm..
ma hai effettivamente constatato che l'accesso mutuamente esclusivo alla lista da problemi di performance?
perchè da quanto vedo stai usando delle API di rete..
e generalmente la latenza delle API di rete è migliaia di volte quella dell'accesso mutuamente esclusivo ad una lista.
Quindi ad occhio, il collo di bottiglia andrebbe ad essere quasi sicuramente la comunicazione di rete, non certo l'accesso condiviso ad una lista.... :mbe:

[mad_hhatter]

mmm..
ma hai effettivamente constatato che l'accesso mutuamente esclusivo alla lista da problemi di performance?
perchè da quanto vedo stai usando delle API di rete..
e generalmente la latenza delle API di rete è migliaia di volte quella dell'accesso mutuamente esclusivo ad una lista.
Quindi ad occhio, il collo di bottiglia andrebbe ad essere quasi sicuramente la comunicazione di rete, non certo l'accesso condiviso ad una lista.... :mbe:

hai perfettamente ragione (in effetti non ho ben chiare le implicazioni in fatto di performance dell'uso della keyword synchronized a parte la possibilità che un thread debba attendere :) ).

molte grazie

[mad_hhatter]

a scopo didattico vorrei comunque discutere la mia implementazione, giusto per avere un'idea su come comportarmi nel caso si presenti una situazione simile a quella descritta e in cui la sincronizzazione possa costituire un collo di bottiglia effettivo.

grazie di nuovo

[mad_hhatter]

up :D

[^TiGeRShArK^]

dunque...
Intanto io credo che manterrei la sincronizzazione però userei al posto di un ArrayList un Set in modo da evitare il controllo sul contains e scriverei i metodi add and remove in questo modo:

private void synchronized addRemoteClient(Socket client) {
if (client != null) {
listeners.add(client);
}
}

private void synchronized deleteRemoteClient(Socket client) {
listeners.remove(client);
}

anzichè usare il synchronized su this volendo si potrebbe usare su un oggetto di tipo volatile boolean appartenente a quest'oggetto che in teoria dovrebbe garantire prestazioni migliori dato che tutti gli altri metodi dell'oggetto non vendono lockati.
..Questo però sempre se ricordo ancora qualcosa della maledettissima programmazione multi-threaded :asd:

[^TiGeRShArK^]

Dimenticavo..
Perchè non pouoi adottare la tecnica copy-on-write? :mbe:
Usando la classe CopyOnWriteArraySet, se le operazioni di lettura sono molto maggiori di quelle di inserimento / rimozione (come credo che avvenga in un sistema di questo tipo) e se la cardinalità non è troppo elevata (questo lo sai solo tu :p) dovresti risolvere il problema.
Cmq, come ho sempre detto, è inutile fasciarsi la testa prima di rompersela.
Solo col profiling, se eventualmente hai bisogno di soluzioni + prestanti perchè quello è proprio il collo di bottiglia del sistema, allora puoi decidere di usare una di queste due tecniche o di trovarne qualche altra che nel tuo caso specifico vada meglio :p

[mad_hhatter]

Dimenticavo..
Perchè non pouoi adottare la tecnica copy-on-write? :mbe:
Usando la classe CopyOnWriteArraySet, se le operazioni di lettura sono molto maggiori di quelle di inserimento / rimozione (come credo che avvenga in un sistema di questo tipo) e se la cardinalità non è troppo elevata (questo lo sai solo tu :p) dovresti risolvere il problema.
Cmq, come ho sempre detto, è inutile fasciarsi la testa prima di rompersela.
Solo col profiling, se eventualmente hai bisogno di soluzioni + prestanti perchè quello è proprio il collo di bottiglia del sistema, allora puoi decidere di usare una di queste due tecniche o di trovarne qualche altra che nel tuo caso specifico vada meglio :p

hai ragione, usare un metodo synchronized in quei casi è più elegante, ma mi pare che un metodo synchronied semplicemente si traduca in un metodo il cui corpo viene racchiuso in un blocco synchronized che si sincronizza proprio su this.

comunque, non posso usare la copy-on-write perchè avendo più scrittori dovrei gestire il caso di scritture contemporanee: cioè ho il problema di fare il merge delle modifiche...

tutto quello che dici sull'effettiva necessità di rompersi la testa con queste cose è correttissimo, sto solo facendo una discussione di tipo "didattico" per capire quali sono le strategie migliori per gestire questo tipo di situazioni nel caso me ne si presentasse una.

[^TiGeRShArK^]

hai ragione, usare un metodo synchronized in quei casi è più elegante, ma mi pare che un metodo synchronied semplicemente si traduca in un metodo il cui corpo viene racchiuso in un blocco synchronized che si sincronizza proprio su this.

comunque, non posso usare la copy-on-write perchè avendo più scrittori dovrei gestire il caso di scritture contemporanee: cioè ho il problema di fare il merge delle modifiche...

tutto quello che dici sull'effettiva necessità di rompersi la testa con queste cose è correttissimo, sto solo facendo una discussione di tipo "didattico" per capire quali sono le strategie migliori per gestire questo tipo di situazioni nel caso me ne si presentasse una.
infatti i due costrutti sono perfettamente equivalenti.
La variazione era nel caso di sincronizzazione sul booleano volatile :p
Cmq ottimizzazioni migliori imho possono essere effettuate valutando solo caso per caso dato che quelle classiche come il synchronized e il copy-on-write vanno quasi sempre, ma in alcune situazioni potrebbe essere possibile ottenere prestazioni migliori con ottimizzazioni specifiche. :p

[mad_hhatter]

infatti i due costrutti sono perfettamente equivalenti.
La variazione era nel caso di sincronizzazione sul booleano volatile :p
Cmq ottimizzazioni migliori imho possono essere effettuate valutando solo caso per caso dato che quelle classiche come il synchronized e il copy-on-write vanno quasi sempre, ma in alcune situazioni potrebbe essere possibile ottenere prestazioni migliori con ottimizzazioni specifiche. :p

non posso che darti ragione.
grazie mille per l'aiuto :)