Re: Green threads in 1.9.* ?

Tony Arcieri wrote in post #1067845:
> Erlang used to be green threaded, however with the introduction of the
> SMP
> scheduler in R12B Erlang gained native thread/multicore support and
> Erlang
> processes began to run in parallel.
>
> You are colluding terms and that is what is making the discussion
> difficult.

I am using the terms I see in the literature, and in the links provided 
to you above.  I am using the terms in the same way the links provided 
use the terms.

I have not seen any literature say that Erlang is no longer green 
threaded (er, green processed).  In fact I was just reading more stuff 
today that referred to Erlang as having green processes.  Erlang's own 
docs say that it has green processes.

I am reading Erlang documentation right now which which states that an 
Erlang process doesn't amount to much more than a pointer within the 
Erlang VM pointing off to some chunk of code/memory inside the Erlang 
VM, which explains why the processes are so lightweight.

Again, it doesn't say it's a pointer pointing off to something OUTSIDE 
THE VM.  Rather, it points to something WITHIN IT.

Again I say I can spawn off several hundred thousand in a second with my 
crappy notebook (I can't do that with pthreads, kernel threads, OS 
threads, whatever).  Again I say I can have literally millions of the 
things running (latest version of Erlang).  And while doing this, I can 
bring up the OS process viewer, and also view the threads running within 
the processes.  Guess what?  NOTHING CHANGES.  There aren't thousands or 
millions of new processes or threads being added to the OS.  There's the 
same processes/threads that were there before.  In other words, the OS 
doesn't know about any of these new processes I fired off within Erlang, 
and it isn't creating new threads to handle them.  But I can bring up a 
process viewer within Erlang, and the millions of processes I created 
are all right there.

The fact that the Erlang VM can now take advantage of multiple cores and 
move these green processes (which are sparked within the VM and live 
within the VM) between the cores by moving them between VMs running one 
per core (one OS thread per core is the recommended approach) doesn't 
mean the processes aren't green.  Just because they can now actually run 
truly in parallel (because they are running on different VMs which are 
running on different cores) doesn't mean they aren't green.

Can we agree that my Erlang code (compiled to Erlang VM bytecode) has to 
be run within an Erlang VM (I'm not compiling it to native code)?  If 
so, then it means that if some kind of OS or kernel thread was used to 
model Erlang processes, an Erlang VM would have to be fired up for each 
kernel thread to execute my code.  You are talking hundreds of thousands 
of VMs being created per second, and millions running on the system.  Of 
course that doesn't happen.

Erlang didn't change the processes.  It didn't change the threading.  It 
added a scheduler and the infrastructure to allow the green processes 
living within the VM to be scheduled across VMs running on other cores. 
Erlang's own docs recommend running only one VM in a single thread per 
core, because it says you aren't going to get any speedup if you add 
more threads and more VMs per core.

> Sorry to get pedantic, but the term "green threads" was termed
> specifically
> to distinguish the threading models of systems that don't use native
> threads from ones which do (i.e. the opposite of "green threaded" is
> "native threaded").

All systems have always used native threads at some point - otherwise 
the systems couldn't run at all.  At the end of the day, there has 
always been and always will be a native thread running somewhere.  So 
the term "green threaded" doesn't distinguish between systems which 
don't use native threads from ones which do, because at the end of the 
day they all do.  The term "green threaded" (or in Erlang's case, "green 
processed") refers to whether or not and how virtual threads or 
processes being created and living in the VM map to 'real threads' in 
the OS.

Therefore, if you have a system that spawns one 'real thread' (call it a 
kernel thread, a pthread, whatever) on the OS for each thread that is 
spawned in the VM, then it is not green threaded - the threads are OS 
threads.  If you have a system that spawns no 'real threads' on the OS 
for any threads created in the VM, you have a green threaded system.

> As soon as you have parallel OS threads (i.e. on a
> multicore computer) managing the scheduling of multiple userspace
> threads/"microthreads", you no longer have a "green threaded" system,
> you
> have one which is using native threads.

That's entirely incorrect, because you could have one thread running on 
each core, with a single GREEN-THREADED VM running on each of those 
threads (x cores, x threads total, x VMs running total).  This is what 
Erlang does now.  The only thing different now than in the past is that 
the VMs will communicate back and forth and schedule their GREEN THREADS 
across each other.

-- 
Posted via http://www.ruby-forum.com/.