www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How multithreading works in hardware using D ==AND== difference b/w

reply "Sparsh Mittal" <sparsh0mittal gmail.com> writes:
Hello

I could find this for Java, but not yet for D and so wanted to 
ask:

Would you tell briefly, how multi-threading in D works on 
hardware. What I wanted to ask is: if we have a single-core or 
multicore system, how does scheduling of threads in D happens.

For Java, what I found was (in my words):

The JVM runs as a single process which internally spawns many 
threads. When the scheduler code running inside the JVM asks for 
another thread, JVM starts another thread. The execution of the 
threads is done using timeslicing, which enables threads to share 
the processor. With this approach, concurrency using 
multithreading can be achieved even on single processors. On 
multicore platforms, these threads can possibly be scheduled on 
different CPU cores. In hardware, the management of thread is 
done by the operating system (OS), and the JVM uses the facility 
provided by the OS.


My second question is: What is the difference between working of 
goroutine in Go and threads spawned in D. Both work concurrently 
with the caller (parent).

Correct me wherever wrong.

My interest in D and Go is using them for parallelizing 
scientific applications.
Nov 25 2012
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 25.11.2012 20:29, schrieb Sparsh Mittal:

 Hello

 I could find this for Java, but not yet for D and so wanted to ask:

 Would you tell briefly, how multi-threading in D works on hardware. What
 I wanted to ask is: if we have a single-core or multicore system, how
 does scheduling of threads in D happens.

 For Java, what I found was (in my words):

 The JVM runs as a single process which internally spawns many threads.
 When the scheduler code running inside the JVM asks for another thread,
 JVM starts another thread. The execution of the threads is done using
 timeslicing, which enables threads to share the processor. With this
 approach, concurrency using multithreading can be achieved even on
 single processors. On multicore platforms, these threads can possibly be
 scheduled on different CPU cores. In hardware, the management of thread
 is done by the operating system (OS), and the JVM uses the facility
 provided by the OS.


 My second question is: What is the difference between working of
 goroutine in Go and threads spawned in D. Both work concurrently with
 the caller (parent).

 Correct me wherever wrong.

 My interest in D and Go is using them for parallelizing scientific
 applications.



Your explanation for Java is not fully correct. The JVMs are free to 
make use of green threads, also know as user space threads, in such 
cases you don't have really a 1:1 mapping to OS threads and scheduling
is limited to blocking operations. Although most VMs nowadays make use
of real threads.

In D's case, it depends. If you are making use of threading APIs 
directly then you have 1:1 mapping to OS threads, but if you use actors
or std.parallelism module, then you have a N:1 mapping between tasks and 
OS threads.

D developers please correct me, if I am wrong.

--
Paulo
Nov 25 2012
parent reply "Sparsh Mittal" <sparsh0mittal gmail.com> writes:
 In D's case, it depends. If you are making use of threading 
 APIs directly then you have 1:1 mapping to OS threads, but if 
 you use actors
 or std.parallelism module, then you have a N:1 mapping between 
 tasks and OS threads.


Thanks a lot for your prompt reply.

I am using: std.concurrency and core.thread. Then, I spawn 
threads as:
spawn(&singleWorker, thisTid);

So, would you tell which category (from what you told) my code 
falls into.
Nov 25 2012
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 25.11.2012 20:54, schrieb Sparsh Mittal:

 In D's case, it depends. If you are making use of threading APIs
 directly then you have 1:1 mapping to OS threads, but if you use actors
 or std.parallelism module, then you have a N:1 mapping between tasks
 and OS threads.


 Thanks a lot for your prompt reply.

 I am using: std.concurrency and core.thread. Then, I spawn threads as:
 spawn(&singleWorker, thisTid);

 So, would you tell which category (from what you told) my code falls into.


I that case you get 1:1 mapping to OS threads, if I am not mistaken.

--
Paulo
Nov 25 2012
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
11/25/2012 11:54 PM, Sparsh Mittal пишет:

 In D's case, it depends. If you are making use of threading APIs
 directly then you have 1:1 mapping to OS threads, but if you use actors
 or std.parallelism module, then you have a N:1 mapping between tasks
 and OS threads.


 Thanks a lot for your prompt reply.

 I am using: std.concurrency and core.thread. Then, I spawn threads as:
 spawn(&singleWorker, thisTid);

 So, would you tell which category (from what you told) my code falls into.


The real 1:1 OS thread. There was talk of using green threads for 
std.concurrency but it's not happening in the near future.


-- 
Dmitry Olshansky
Nov 25 2012
parent "Sparsh Mittal" <sparsh0mittal gmail.com> writes:
 The real 1:1 OS thread. There was talk of using green threads 
 for std.concurrency but it's not happening in the near future.


Thanks for your reply and confirmation.

Would anyone also kindly answer the second question. Thanks.
Nov 25 2012
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Nov 25, 2012, at 11:54 AM, Sparsh Mittal <sparsh0mittal gmail.com> =
wrote:


=20
 In D's case, it depends. If you are making use of threading APIs =




directly then you have 1:1 mapping to OS threads, but if you use actors

 or std.parallelism module, then you have a N:1 mapping between tasks =




and OS threads.

 Thanks a lot for your prompt reply.
=20
 I am using: std.concurrency and core.thread. Then, I spawn threads as:
 spawn(&singleWorker, thisTid);
=20
 So, would you tell which category (from what you told) my code falls =


into.

Today, std.concurrency is backed exclusively by kernel threads.  At some =
point in the future it's possible that will change.  The trick there is =
properly handling global statics, as those are thread-local, not =
fiber-local.=
Nov 27 2012
prev sibling next sibling parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 11/25/2012 11:29 AM, Sparsh Mittal wrote:


 What is the difference between working of
 goroutine in Go and threads spawned in D. Both work concurrently with
 the caller (parent).


As far as I know, goroutines are coroutines with a more appropriate name 
for the language. :) There is not necessarily a thread involved but I 
think the implementation does multiplex them on threads. (?)

I think the closest thing in D is a Fiber:

   http://dlang.org/phobos/core_thread.html#Fiber

Ali
Nov 25 2012
parent "Sparsh Mittal" <sparsh0mittal gmail.com> writes:
 I think the closest thing in D is a Fiber:

   http://dlang.org/phobos/core_thread.html#Fiber

 Ali


Thanks a lot. That was very helpful.
Nov 25 2012
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-11-25 20:29, Sparsh Mittal wrote:


 My interest in D and Go is using them for parallelizing scientific
 applications.


D has the std.parallelism module. It has parallel foreach, map, reduce 
and similar functions.

http://dlang.org/phobos/std_parallelism.html

-- 
/Jacob Carlborg
Nov 25 2012
prev sibling next sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Sunday, 25 November 2012 at 19:29:43 UTC, Sparsh Mittal wrote:

 Hello

 I could find this for Java, but not yet for D and so wanted to 
 ask:

 Would you tell briefly, how multi-threading in D works on 
 hardware. What I wanted to ask is: if we have a single-core or 
 multicore system, how does scheduling of threads in D happens.

 For Java, what I found was (in my words):

 The JVM runs as a single process which internally spawns many 
 threads. When the scheduler code running inside the JVM asks 
 for another thread, JVM starts another thread. The execution of 
 the threads is done using timeslicing, which enables threads to 
 share the processor. With this approach, concurrency using 
 multithreading can be achieved even on single processors. On 
 multicore platforms, these threads can possibly be scheduled on 
 different CPU cores. In hardware, the management of thread is 
 done by the operating system (OS), and the JVM uses the 
 facility provided by the OS.


 My second question is: What is the difference between working 
 of goroutine in Go and threads spawned in D. Both work 
 concurrently with the caller (parent).

 Correct me wherever wrong.

 My interest in D and Go is using them for parallelizing 
 scientific applications.


Your second question was indirectly answered already by informing 
you about Fibers. The difference is exactly the same as 
difference between D's Fibers and Threads.
Nov 27 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11/27/2012 01:03 PM, Dejan Lekic wrote:

 On Sunday, 25 November 2012 at 19:29:43 UTC, Sparsh Mittal wrote:

 Hello

 I could find this for Java, but not yet for D and so wanted to ask:

 Would you tell briefly, how multi-threading in D works on hardware.
 What I wanted to ask is: if we have a single-core or multicore system,
 how does scheduling of threads in D happens.

 For Java, what I found was (in my words):

 The JVM runs as a single process which internally spawns many threads.
 When the scheduler code running inside the JVM asks for another
 thread, JVM starts another thread. The execution of the threads is
 done using timeslicing, which enables threads to share the processor.
 With this approach, concurrency using multithreading can be achieved
 even on single processors. On multicore platforms, these threads can
 possibly be scheduled on different CPU cores. In hardware, the
 management of thread is done by the operating system (OS), and the JVM
 uses the facility provided by the OS.


 My second question is: What is the difference between working of
 goroutine in Go and threads spawned in D. Both work concurrently with
 the caller (parent).

 Correct me wherever wrong.

 My interest in D and Go is using them for parallelizing scientific
 applications.


 Your second question was indirectly answered already by informing you
 about Fibers. The difference is exactly the same as difference between
 D's Fibers and Threads.


Not really. "goroutines" typically have a smaller memory footprint 
because they use a growable stack and they are multiplexed to threads by 
the runtime. Fibers need to be scheduled manually.
Nov 27 2012
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Nov 25, 2012, at 11:29 AM, Sparsh Mittal <sparsh0mittal gmail.com> =
wrote:


 Hello
=20
 I could find this for Java, but not yet for D and so wanted to ask:
=20
 Would you tell briefly, how multi-threading in D works on hardware. =


What I wanted to ask is: if we have a single-core or multicore system, =
how does scheduling of threads in D happens.

=20
 For Java, what I found was (in my words):
=20
 The JVM runs as a single process which internally spawns many threads. =


When the scheduler code running inside the JVM asks for another thread, =
JVM starts another thread. The execution of the threads is done using =
timeslicing, which enables threads to share the processor. With this =
approach, concurrency using multithreading can be achieved even on =
single processors. On multicore platforms, these threads can possibly be =
scheduled on different CPU cores. In hardware, the management of thread =
is done by the operating system (OS), and the JVM uses the facility =
provided by the OS.

D is the same.  In essence, a Thread in D is equivalent to a kernel =
thread and in fact forwards all of the real work to the appropriate =
kernel calls.



 My second question is: What is the difference between working of =


goroutine in Go and threads spawned in D. Both work concurrently with =
the caller (parent).

A D Fiber is closer to a goroutine, but Fibers are still somewhat =
simpler / lower-level.  The stack for a Fiber is allocated on creation =
and fixed in size, and scheduling is done manually via the call() =
method.=
Nov 27 2012