From: rex goxman Date: 2012-07-08T18:19:16+09:00 Subject: 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/.