James Robertson points out the difference between "native" OS threads and threads implemented in the language runtime. Some people (as quoted) see mapping language-level threads to OS threads as a good thing.
In part this may come from Java's first implementation of threads (aka "green" threads, a term Jim also applies to VW Smalltalk's threads). These had their share of implementation problems early on and so before long the Java community seemed to gravitate toward an anti-green-thread attitude at the conceptual level. Only now for example is BEA's JRocket JVM *experimenting* with a high-performance non-native thread implementation they call "thin threads" (wisely avoiding the "green" label).
As VW Smalltalk, Gambit and PLT Scheme, Erlang, and the Oz language demonstrate, highly concurrent programming requires much lighter-weight mechanisms than OS threads. (For the typical OS.)
Apparently most Common Lisp systems have heavy thread implementations and so the ErLisp implementation may not scale up as well as these other systems either.
4 comments:
"As VW Smalltalk, Gambit and PLT Scheme, Erlang, and the Oz language demonstrate, highly concurrent programming requires much lighter-weight mechanisms than OS threads. (For the typical OS.)"
At most, they demonstrate that highly concurrent programming can be done with "green" threads. Require? I don't think so.
Highly concurrent threading on OS threads for some of the most popular OS's (Linux and Windows at least) has been demonstrated to require more time to start threads and more space per thread. Let's put it that way.
What a wonderful invention it is, this thing we call the Internet!
It pretty much covers FREE Marketing related stuff.
Post a Comment