On Wed, 2010-08-18 at 20:48 +0000, nsf wrote: > Hi. I'm trying to replicate in D my Go demo app which basically > draws mandelbrot fractal using multiple goroutines. In Go it's > fairly easy to communicate between threads, because the memory model > is C like. D 2.0 on the other hand has this thing "TLS by default". > And I saw simple examples of std.concurrency usage in Andrei's book, > but what about more complex ones.
For the little experiments I am doing in D and Go, I am finding that the solution architectures are surprisingly similar. Goroutines, channels and message passing in Go compare to spawning and message passing in D. Yes the underlying semantics are very different in many ways, but it is process and message passing as an architectural direction. In neither case do I actually care about threads and thread pools, etc. The whole point is to get away from shared-memory multithreading as a programming model and treat it as an enabling model. Processors, cores and threads are like memory, heaps and stacks, programmers know they are there, but they let the runtime system deal with them. Of course having a sensible parallel algorithm compared to a sequential algorithm matters, but I am assuming you already have that covered. -- 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...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
