<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-05-24 14:30 GMT+01:00 Manlio Perillo <span dir="ltr"><<a href="mailto:manlio.perillo@gmail.com" target="_blank">manlio.perillo@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
</span>Quando parlo di memoria condivisa intendo a dettaglio implementativo,<br>
magari nascosto sotto l'astrazione di una libreria o di un linguaggio.<br>
Ad esempio in Rust alla fine *usi* memoria condivisa, ma il linguaggio<br>
ti permette di ragionare senza pensare a sincronizzazioni esplicite.<br>
<br>
In Go puoi usare i channel, ma anche qui alla fine usi la memoria<br>
condivisa, solo che la sincronizzazione è gestita dal runtime.<br></blockquote><div><br></div><div>Si ok... ma visto e considerato che i computer sono delle macchine di von neumann ad un certo punto le cose sono implementate con dei gran TSL o quello che ha la tua CPU.</div><div>Quello che e' interessante e' che il modello che stai usando e' fatto in termini di message passing (o qualunque altra primitiva di concorrenza che non sia tirare dei gran lock e pedalare).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ma sempre in Go, spesso la soluzione più semplice e suggerita in<br>
mailing list, è quella di usare un mutex.</blockquote><div><br></div><div>A volte, si. Quando la soluzione con i channel non e' sufficiente o diventa troppo complicata o troppo inefficiente. </div><div>E ancora una volta quello che cerchi di fare e' fare in modo che lo stato sia *localmente* mutabile e di avere controllo su chi e come lo vuole scrivere e leggere.</div><div><br></div><div><br></div><div><br></div></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>