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.

On Nov 25, 2012, at 11:29 AM, Sparsh Mittal <sparsh0mittal@gmail.com> 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.

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.

On Nov 25, 2012, at 11:54 AM, Sparsh Mittal <sparsh0mittal@gmail.com> wrote:

>> 
>> 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.

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.