On Sat, 2015-03-14 at 12:54 -0700, Andrei Alexandrescu via Digitalmars-d wrote: > On 3/14/15 11:24 AM, Russel Winder via Digitalmars-d wrote: > > But yes, it certainly shows you can create shared-memory > > "multi-threading" this way, > > So your affirmation has been refuted.
It appears so, I grovel at the feet of logic and proof. The core issue here is the ability to ship memory addresses around instead of having to ship values. I still believe dataflow to be the superior architecture for concurrent and parallel systems. Actian Datarush and GPars are on the JVM and avoid Unsafe, and whilst you can set up sharing of mutable data structures, it is a lot harder than as in Go. Likewise with Python-CSP and PyCSP sending values that are not references to shared mutable state is the norm. It is quite hard to do otherwise with Python as a consequence of the GIL and the necessity to use multiprocessing (i.e. each process is a separate PVM and hence separate OS process, and hence different address space). > > but anyone actually doing it would be being > > very silly. > > That's "design by prayer". Aren't most bugs created by people doing very > silly things? And prayer achieves nothing. I think you can probably remove the "very" there and it still be right. > > Sending addresses down multiple channels > > One is enough. Actually no, you need two. I believe you are thinking that the sender retains the reference and sends the reference so one send is enough. True per se. But what Rust is trying to enforce, which C++ (and D?) do not, is ownership of the reference, so that you can send a reference the originator cannot then use. Clearly std::unique_ptr is trying to provide this for C++ but it isn't enforced as has to be to avoid the situation you coded up in Go. > > > is obvious here and > > definitely not the right thing to do unless the datum contains an > > embedded lock which is then used. cf. > > https://talks.golang.org/2012/10things.slide#3 > > Yes, of course it's not the right thing to do. Your point being...? A language has to enforce not manipulating shared mutable memory or the programs will likely be broken. Functional programming's obsession with copying rather than sharing, helps with this. > > It would be better if channels could only accept value types, and not > > reference types. > > Probably not as that would further hamstrung the language. I am not sure that is true. I find it somewhat strange that Go allows sharing of references to mutable state in this way, it certainly doesn't fit with the way I was brought up to use dataflow. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
