|Welcome to the Monastery|
Re^14: Utter crud! ("threads")by tye (Cardinal)
|on Oct 28, 2010 at 21:36 UTC||Need Help??|
Erlang "threads" are also called Erlang "processes" and they neither have shared data/state nor wholesale copies of data. I don't often see them referred to as just "threads", probably because they aren't much like C, nor C++, nor Java, nor Modula-2, nor Visual BASIC, nor Unix kernel threads nor Win32 native threads (nor are they much like iThreads nor fork).
You can create and destroy Erlang "processes" similar to what one might be used to with threads in a procedural language (since Erlang is functional but also is all about interfacing with things in the Real World).
Haskell has more emphasis on the "functional" (the meaning from computing theory, not plain English) and less on the "interfacing" and so "threads" there tend to be more just purely useful for using more CPUs at once in hopes of finishing sooner and you don't so much control the "threads" as you declare where the compiler is allowed to make use of threads for you.
Purely functional programs don't have a traditional flow, traditional "blocking" operations, nor variables much less shared variables, so traditional threads just don't really apply much.
A lot of times you'll see things called "threads" with some qualifier(s) and then described as "not the same as 'vanilla' threads" and then called "light-weight processes". Unfortunately, you can't call iThreads "light-weight processes" since in some significant ways they weigh more than vanilla processes.
So, iThreads are actually more like fork than like any of these things that are sometimes calls "threads" in other languages. And the things that aren't pretty much exactly like C threads and Unix kernel threads don't tend to get called just plain "threads" much, IME.
Though, their emulation of the lion's share of work done by fork() (copy of the majority of the process, not the myriad bookkeeping bits like setting the program counter or assigning PIDs, etc.) is significantly less efficient than fork().
iThread's copying used 10x more CPU in the trivial case. It was trivial to create some data and make iThread's copying use 100x the CPU of fork(). Even if I pessimize for fork() by modifying all of the initial data so it all gets unshared, iThreads still used just over 70x more CPU.
Comparing memory usage is not trivial so I didn't try to come up with any numbers to compare that.
But that only applies to (part of) why I don't use iThreads in Unix. I look forward to trying to use iThreads again under Windows.
The name iThreads has probably discouraged use of the technology. I find many eschew threads, often in a rather stark "threads vs fork" mindset. Well, iThreads have more in common with multi-tasking via fork than with traditional multi-tasking via threads, so an ardent "fork not threads!" stancer should well consider iThreads, certainly before threads.
I tend to focus more on the details of communication between the parts (solid interfaces lead to solid systems) and so don't tend to reach for the convenient "share a few variables willy, nilly" framework. But iThreads have advantages and can be used effectively even in Unix (yes, you usually need to be aware of their disadvantages; for example, don't spawn a new thread for each little task).