www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is the new D threading model emulating processes + shared memory?

reply Leandro Lucarella <llucax gmail.com> writes:
I was thinking about the thread "Sharing in D" and it came up to my mind
that what it's been done with this model is just emulating processes +
shared memory. If you program you application with processes instead of
threads and shared memory instead of "D shared" type (or global variables
in general), you get what D is trying to do: clearly separated memory
areas for shared and unshared data, and protection.

So, what are the advantages of using threads+shared in D 2.0 compared with
processes+shared memory in D 1.0? I guess it's just simpler to program,
and maybe, more familiar to "threads programmers" (people that are not
very used to program using processes). Well, I guess you can have a little
faste context switches too, but I don't think this his a huge gain in
modern operating systems.

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Yo soy Peperino él que nunca toma vino, yo soy aquel que por la mañana
escucha Salatino.
	-- Peperino Pómoro
Aug 01 2008
next sibling parent superdan <super dan.org> writes:
Leandro Lucarella Wrote:

 I was thinking about the thread "Sharing in D" and it came up to my mind
 that what it's been done with this model is just emulating processes +
 shared memory. If you program you application with processes instead of
 threads and shared memory instead of "D shared" type (or global variables
 in general), you get what D is trying to do: clearly separated memory
 areas for shared and unshared data, and protection.
that's real deep. changed the way i look at this shit. until now i was comparing the model with the perl shit. perl in concept does the same as d2. i used that perl model and like it a ton. it's slow tho because perl copies the whole heap to boot. but i think u r right. it's like processes and shared memory. and you know what. i wrote those and never had a problem. problem is with threads because everything is shared by default without anyone wanting or knowing. only little should be shared. sharing must be controlled. seems d2 has the right view.
 So, what are the advantages of using threads+shared in D 2.0 compared with
 processes+shared memory in D 1.0? I guess it's just simpler to program,
 and maybe, more familiar to "threads programmers" (people that are not
 very used to program using processes). Well, I guess you can have a little
 faste context switches too, but I don't think this his a huge gain in
 modern operating systems.
to boot there is the overhead. creating a process is much a bigger deal than a thread. new tables and shit. then shared memory access costs too i recall. then also creating and dealing with shared memory is not for the faint of heart. for example pointers are meaningless unless you are really cautious and shit. and no typechecker tells you that. in d2 it looks like the type of shared memory is doing the right thing because it's transitive.
Aug 01 2008
prev sibling parent "Lionello Lunesu" <lionello lunesu.remove.com> writes:
"Leandro Lucarella" <llucax gmail.com> wrote in message 
news:20080801144452.GA4673 burns.springfield.home...
I was thinking about the thread "Sharing in D" and it came up to my mind
 that what it's been done with this model is just emulating processes +
 shared memory. If you program you application with processes instead of
 threads and shared memory instead of "D shared" type (or global variables
 in general), you get what D is trying to do: clearly separated memory
 areas for shared and unshared data, and protection.
I think this analogy is pretty good! Sure helps explaining the plan.
 So, what are the advantages of using threads+shared in D 2.0 compared with
 processes+shared memory in D 1.0? I guess it's just simpler to program,
 and maybe, more familiar to "threads programmers" (people that are not
 very used to program using processes). Well, I guess you can have a little
 faste context switches too, but I don't think this his a huge gain in
 modern operating systems.
Well, threads use the same virtual memory, that's a huge plus. For example, the software I'm currently working on is a 3D product that uses 1 thread for rendering and the other for loading 3D resources. This is impossible to do with processes. L.
Aug 07 2008