Lambda the Ultimate

"Green thread" or "microthread" are some of the more generic terms used here. I'm not sure if the erlang team called them processes because they felt the name was more descriptive, or because they thought something like 'microthread' would be dismissed in the same way that people dismiss 'scripting languages'. There are a few big differences compared to 'normal' threads.

First is that they require much lower overhead. Normal threads create a stack for each thread which ends up hogging memory if you try to create hundreds or thousands of threads.

Second is that switching between threads is controlled by the application, not the OS.

Third is that processes are isolated and the only permissible way to exchange information is message passing. This eliminates the need to use mutexes, semaphores, etc, and simplifies writing thread safe code.

Anyway, if you do some research on green threads or microthreads, you'll get some pretty good general information on the differences compared to OS threads. Most should be applicable to erlang.

These days much (most?) of the expense of a context switch is all the cache lines that are suddenly stale. I'd expect thread switches to incur this cost whether or not the operating system was involved.

bend: i'd like to find out about the differences between erlang processes and pthreads threads [snip...] how processes and threads differ and what those differences mean/amount to.

I think about this a lot in a long-running design problem I'm cooking on a mental backburner. (If I write a FAQ for a new runtime someday, one question might easily be this one. :-) I very nearly wrote on this topic in a recent LtU thread on "fixing Lisp", but my reply got out of hand, so I shelved it. But I'll include a part of it in this post: I picked the phrase russian doll process architecture to name an idea. (Pronouce rudopa the same as Europa: roo-DOH-puh.)

The distinguishing characteristic of a process (as opposed to thread) usually has something do with with the address space. For example, a process is typically described as having an address space independent from other processes. Under Linux for example, each process has a separate address space (if you ignore shared memory). Threads are control flows with concurrent access to the same memory, which introduces the whole mutable shared memory access control problem.

But what you really mean by process and address space might depend on your runtime and how narrowly you want to define things. You can get different sorts of process like results by allowing variations in what you mean by address space, where each variation focuses on the idea of keeping memory partitions disjoint from one another. You can use more than one together at the same time in one runtime. You can even nest them inside one another, as in the classic russian doll meme.

Assuming you want to host a runtime in some existing operating system, you'll take one process as given from the host OS. But inside this process you can have lightweight processes. If you only had two kinds of process -- host and lightweight -- then you'd be able to get by with the idea of lightweight process alone. However, you can have more than one type of lightweight process, and they can also nest inside each other. (I thought rudopa -- for russian doll process architecture -- was a plausible way to refer to this.)

An Erlang process fits the address space qualification for process because Erlang data is immutable. If you can't ask objects about their addresses, and if you can't change state to leave breadcrumbs for analysis, then you have no objective means to detect the scope of an address space. So if Erlang messaging objects don't send data to each other, they might as well be in different address spaces becuase they can't interfere with each other in a shared mutable state scenario. (You can also share state between lightwieght processes and this is undetectable if the state doesn't change; so sharing this way is an optimization over indepedent copies.)

There are at least a couple other ways to do lightweight processes, and I expect to use both of them in addition to the Erlang style immutable state event handlers. (Let's use const process to refer to an Erlang style process.) First, you can have a VM with disjoint address spaces enforced by the VM, so multiple lightweight process in one host process can't affect one another. Let's call this a sandbox process. Second, you can have a memory allocation runtime partitioning one host address space into disjoint graphs of objects, so each is partition is garbage collected independently of any other. Let's call each of these a plot process (using a real estate metaphor for land plots), since disjointness is nominal but legally mediated by the runtime (you can ask whether an address is inside your plot).

Anyway, each of the process models give you a different form of management and control over memory usage, and each has a different take on avoiding interference under concurrency without using synchronization mechanisms, because no mutable state is shared.

Inside a host process you can have multiple plot processes (and maybe some sandbox processes), and in each plot process you might have a way to mark memory as immutable so it can be fed into Erlang style handlers that run as const processes.

ToonTalk's houses would be const processes, I suppose, if they are written without using sensors (leaving bird and nest as the only communication). And I see no particular reason why they would need stacks, so they are probably pretty green.

As in the actor model, when a house "fires", it cannot loop nor hang, so can't take long to finish its turn. It's basically executing a rewrite rule.