[LUGSB] Multithreading or Light-weight processes ?

[Chris Wright]

2008/10/19 Arjun G. Menon <arjungmenon at gmail.com>:
> Hi LUGSB,
>
> I guess most of you must have worked with threads at some point and
> are familiar with the difficulty involved in writing complex
> applications that use them. I think the best way to overcome this
> "thread problem"
> (http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf) is
> by using light-weight processes.

You really need very good support for IPC in that case. Erlang has
language support for message passing, so that eliminates most of the
pain associated with IPC.

Plus if you're using userspace processes, your IPC will probably be
shared memory, so you'll need some means of protecting that. Plus
you're relying on cooperative multitasking, unless you have language
support. Though any time a process passes a message, you can pause
that process and run the scheduler, so you don't need to worry about
that overmuch. And the scheduler would be able to tell you which
processes are taking the largest time slices when there is contention,
and you can pepper the relevant methods with yields.

I was wondering, just now, how you'd handle the issue of multiple
processes attempting to work on shared data. But you can simply make
the shared data structure into another process, and manipulating it
will consist of passing messages to it.

> I personally feel using light-weight processes for intra-application
> multitasking is far more superior than having concurrently running
> threads that share the same block of memory. Light-weight processes
> are far more secure than threads in the sense they don't share memory
> and thus avoid a whole host of problems associated with it. IMO, they
> are also easier to work with (while programming); I find the
> message-passing IPC model simpler and more manageable.
>
> Additionally when it comes to parallel computing; even there
> light-weight processes are a win-win scenario. There's no need for
> complex algorithms that manage shared memory between CPUs when each
> CPU can be assigned 1/more L.W.-processes and they all interact by
> message passing. I think on a well designed OS, L.W.-procs should be
> as efficient as threads.

Additionally, light weight processes don't share memory, so there are
some compiler optimizations you can do. And, for instance, you could
run a garbage collector on just the memory associated with one light
weight process, speeding up collection times without sacrificing
accuracy.

Also, switching between light weight processes takes something like 32
instructions on x86 processors, so that's fast. But again, any sort of
multithreading in the scheduler / runtime would require a lot of
locking. It's just that you don't have to handle it manually. Since
there's probably opportunity to use, develop, and improve lock-free
messaging in light weight processes, and that's only one relatively
small body of code to alter, that's a very good tradeoff.

> Some applications like Google Chrome already use L.W.-procs (for each
> tab the user opens a seperate process is launched). It surprises me
> that a lot more people don't use it already, given its many
> advantages. Which model of multitasking do you think is better?
> (especially in terms of programmer efficiency)

In Chrome's case, the processes aren't very light weight. Chrome uses
more memory than Firefox, and that's not easy.