CMUCL: concurrent programming questions
Quote:
>[Eric Marsden]
>>It's also worth noting that Dan Barlow's work on native threads for
>>SBCL on Linux/x86 will lead to much better multiprocessing support
> How light/heavyweight are those thread implementations in comparison?
Nobody's benchmarked, as far as I know. My motivation for a 1:1 model
is
* much simpler to deal with foreign code that may block (stream IO
in SBCL is already kind of baroque and has strange bugs; why make
it harder?)
* take advantage of SMP machines
* and the killer: there are many more Linux kernel hackers being paid
to improve the efficiency of kernel threads than there are of me.
Even though userland threads potentially can be scheduled more
efficiently, the number of performance wizards in each court
strongly suggests that OS-level scheduling is the way to go in
practice
Quote:
> I think that 1:1 mapping of high level threads to OS threads is
> quite expensive, and I'd really like something like Erlang wrt
Thread creation is expensive in that each thread requires a binding
stack, a control stack, etc etc. Thread switch costs about as much as
a process context switch, less the tlb flushes because they all have
the same memory maps. The current implementation is limited to 8192
threads because that's all we can get in an LDT (the new NPTL stuff in
linux 2.6 can fix this, but we don't take advantage of it yet).
Quote:
> concurrency (and perhaps another few goodies), and like (Common)
> Lisp wrt all the rest.
I don't think the CMUCL model is what you're looking for here either,
that said. I've not used Erlang, but my impression is that Erlang
programmers use threads for pretty much anything they feel like, and I
doubt that CMUCL's threads (which wind/unwind the binding stack on
each switch) are quite up to this either. But someone who knows
Erlang (Luke Gorrie, if he reads cll) would be more qualified to
comment here.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources