Jump to page: 1 2
Thread overview
How multithreading works in hardware using D ==AND== difference b/w goroutine and threads in D
Nov 25, 2012
Sparsh Mittal
Nov 25, 2012
Paulo Pinto
Nov 25, 2012
Sparsh Mittal
Nov 25, 2012
Paulo Pinto
Nov 25, 2012
Dmitry Olshansky
Nov 25, 2012
Sparsh Mittal
Nov 27, 2012
Sean Kelly
Nov 25, 2012
Ali Çehreli
Nov 25, 2012
Sparsh Mittal
Nov 26, 2012
Jacob Carlborg
Nov 27, 2012
Dejan Lekic
Nov 27, 2012
Timon Gehr
Nov 27, 2012
Sean Kelly
November 25, 2012
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.


November 25, 2012
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
November 25, 2012
>
> 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.



November 25, 2012
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
November 25, 2012
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
November 25, 2012
> 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.


November 25, 2012
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

November 25, 2012
>
> 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.
November 26, 2012
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
November 27, 2012
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.
« First   ‹ Prev
1 2