What high level languages support multithreading?

Question

I'm wondering which languages support (or don't support) native multithreading, and perhaps get some details about the implementation. Hopefully we can produce a complete overview of this specific functionality.

Answer 1

ANSI C/C++ has no support at all. POSIX threads (pthreads) are available on a number of platforms, including *nix and Mac OS X; Windows has its own threading library.

Answer 2

I believe that the official squeak VM does not support native (OS) threads, but that the Gemstone version does.

(Feel free to edit this if not correct).

Answer 3

You need to define "native" in this context.

Java claims some sort of built-in multithreading, but is just based on coarse grained locking and some library support. At this moment, it is not more 'native' than C with the POSIX threads. The next version of C++ (0x) will include a threading library as well.

Answer 4

I know Java and C# support multithreading and that the next version of C++ will support it directly... (The planned implementation is available as part of the boost.org libraries...)

Answer 5

Perl and Python do. Ruby is working on it, but the threads in Ruby 1.8 are not really threads.

Answer 6

Boost::thread is great, I'm not sure whether you can say its part of the language though. It depends if you consider the CRT/STL/Boost to be 'part' of C++, or an optional add-on library.

(otherwise practically no language has native threading as they're all a feature of the OS).

Answer 7

With CPython, one has to remember about the GIL. To summarize: only one processor is used, even on multiprocessor machines. There are multiple ways around this, as the comment shows.

Answer 8

Erlang has built-in support for concurrent programming.

Strictly speaking, Erlang processe are greenlets. But the language and virtual machine are designed from the ground up to support concurrency. The language has specific control structures for asynchronous inter-process messaging.

In Python, greenlet is a third-party package that provides lightweight threads and channel-based messaging. But it does not bear the comparison with Erlang.

Answer 9

Delphi/FreePascal also has support for threads.

I'll assume, from other answers, that it's only native on the Windows platforms.

Some nice libraries that implement better features on top of the TThread Object:

• OmniThreadLibrary
• BMThread

Answer 10

I suppose that the list of languages that are higher-level than Haskell is pretty short, and it has pretty good support for concurrency and parallelism.

Answer 11

This question doesn't make sense: whether a particular implementation chooses to implement threads as native threads or green threads has nothing to do with the language, that is an internal implementation detail.

There are Java implementations that use native threads and Java implementations that use green threads.
There are Ruby implementations that use native threads and Ruby implementations that use green threads.
There are Python implementations that use native threads and Python implementations that use green threads.
There are even POSIX Thread implementations that use green threads, e.g. the old LinuxThreads library or the GNU pth library.

And just because an implementation uses native threads doesn't mean that these threads can actually run in parallel; many implementations use a Global Interpreter Lock to ensure only one thread can run at a time. On the other hand, using green threads doesn't mean that they can't run in parallel: the BEAM Erlang VM for example can schedule its green threads (more precisely green processes) across mulitple CPU cores, the same is planned for the Rubinius Ruby VM.

Answer 12

Perl doesn't usefully support native threads.

Yes, there is a Perl threads module, and yes it uses native platform threads in its implementation. The problem is, it isn't very useful in the general case.

When you create a new thread using Perl threads, it copies the entire state of the Perl interpreter. This is very slow and uses lots of RAM. In fact it's probably slower than using fork() on Unix, as the latter uses copy-on-write and Perl threads do not.

---

But in general each language has its own threading model, some are different from others. Python (mostly) uses native platform threads but has a big lock which ensures that only one runs (Python code) at once. This actually has some advantages.

Aren't threads out of fashion these days in favour of processes? (Think Google Chrome, IE8)

Answer 13

I made a multithreading extension for Lua recently, called Lua Lanes. It merges multithreading concepts so naturally to the language, that I would not see 'built in' multithreading being any better.

For the record, Lua's built in co-operative multithreading (coroutines) can often also be used. With or without Lanes.

Lanes has no GIL, and runs code in separate Lua universes per thread. Thus, unless your C libraries would crash, it is immune to the problems associated with thread usage. In fact, the concept is more like processes and message passing, although only one OS process is used.

Answer 14

Clojure is an up and coming Lisp-dialect for the JVM that is specifically designed to handle concurrency well.

It features a functional style API, some very efficient implementations of various immutable data structures, and agent system (bit like actors in Scala and processes in Erlang). It even has software transactional memory.

All in all, Clojure goes to great lenght to help you write correct multithreaded and concurrent code.