Lambda the Ultimate

The interpretter for my (as of yet unreleased) language Rhope is multi-threaded. I haven't done enough testing to say whether or not it can actually run parallel problems faster with multiple threads. The only real benchmark I've run is naive recursive fibonacci, but that would appear to be memory bandwidth bound in my language currently and actually runs more slowly when the threads are allowed to run on multiple cores. The language doesn't have any explicit threading though. The semantics of the language allow the interpretter to run independent statements in parallel.

I believe Erlang's "processes" are light-weight user level processes, but these processes can be split up amongst kernel threads to take advantage of multi-core/multi-processor machines. Each individual process will execute in a single thread, but an Erlang application as a whole can operate on multiple kernel threads. At least that's how I think it works. I haven't had a chance to use Erlang yet so I'm still a bit fuzzy on certain aspects of the language.

do you mean "utilizing multiple kernel threads"?

Erlang, mentioned above. IIRC, Erlang spawns as many kernel threads as there are CPUs, and then allocates the many Erlang processes among that fixed number of threads.

Most JVMs as well; other than early "green threads" implementations, a JVM will typically map each Java thread onto a native kernel thread. (Are there any JVMs that utilize multiple threads, but map more than one Java thread onto a kernel thread)?

Beyond those, I dunno.

_

Pinku Surana: Are there any thread-safe language interpreters out there that run multi-threaded code?

Probably, but I'd expect only in high end implementations because making code thread-safe is involved. (I do that a lot, so I know a fair amount about it, but I don't have a thread-safe interpreter myself yet for reference.) Pavone's and Johnson's remarks sound exactly correct. I expect JavaScript ought to end up thread-safe soon if it isn't already.

It's easier to answer such questions when you cite motivation, since folks can address motivation as well as just question asked. It's do-able but problematic since you normally need to choose which places are not thread-safe where synchronization is needed, unless you have a model like Erlang where safety is moot when there's no shared mutable state to protect.

Pinku Surana: Python uses a global interpreter lock to run threads one at a time, though it does some meager preemption.

Likely still true since removing that constraint is mentioned often. If someone writes a thread-safe interpreter for language Foo, then implements Python on top of that or on top of the same common runtime, the result could be thread-safe Python. (It's possible some semantics of Python might require races on shared state that are hard to fix -- I don't know.)

Pinku Surana: I think I read somewhere that Erlang is actually single-threaded, though it manages zillions of Erlang "processes". Is that still true?

Erlang should be running a large number of "green threads" as lightweight processes per kernel thread, but with multiple threads and/or multiple processes, so the result is Erlang running with thread-safe concurrent code in the same system. It should still be true that some "green threads" might have no need of protection from pre-emptive threads, so they run like they are single-threaded despite keeping company with other threads. (I'm only familiar with cursory Erlang details, so I could easily be off.)

Neko http://nekovm.org is a Virtual Machine which can run several kernel threads. The same code can be shared among threads, but you have to be careful to use some locks if you want to modify some data structures concurently.

Java is multi-threaded, and if you disable the JIT compiler, then it becomes interpreted.

You can do this from the command-line like this:

Glasgow Haskell's repl uses the SMP runtime in 6.4.2 and newer versions (it has been an option for compiled programs for longer). GHC schedules lightweight user-space threads over a user-specified number of system threads.

Tcl has threads for quite long now.

We used them quite succesfully.

JavaScript is famously single-threaded. But the SpiderMonkey JavaScript engine actually does support native threading. Here's how it works: SpiderMonkey Internals: Thread Safety.

Reasons why Python's GIL is not likely to go away soon: Python wiki: GlobalInterpreterLock.

JRuby is an interpreter/compiler for the Ruby language which directly exposes native threads.

In Erlang's case, the modern Erlang runtime schedules an arbitrary number of Erlang processes across a fixed number of hardware threads.