Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
CMUCL threads on Linux x86: are they lightweight?
130 views
Skip to first unread message
Raffaele Ricciardi
Jan 20, 2012, 7:01:35 PM1/20/12
to
Are CMUCL threads on Linux x86 lightweight? Like Gambit or Erlang, I
mean. Or are they native, like SBCL?
I have not been able to figure it out by reading both CMUCL's
documentation and articles citing it, and its mailing-list subscription
system does not work.
Thank you.
mean. Or are they native, like SBCL?
I have not been able to figure it out by reading both CMUCL's
documentation and articles citing it, and its mailing-list subscription
system does not work.
Thank you.
D Herring
Jan 20, 2012, 8:31:46 PM1/20/12
to
If they were user-space ("green"), then I would expect them to be
supported on all platforms.
- Daniel
Raffaele Ricciardi
Jan 20, 2012, 9:31:57 PM1/20/12
to
On 01/21/2012 01:31 AM, D Herring wrote:
> I believe they are native threads like in SBCL.
> If they were user-space ("green"), then I would expect them to be
> supported on all platforms.
It makes sense. Thanks.
> I believe they are native threads like in SBCL.
> If they were user-space ("green"), then I would expect them to be
> supported on all platforms.
CMUCL's docs state: "CMUCL supports Lisp threads for the x86 platform."
and that's it. [1]
After reading your answer I looked up "CMUCL green threads" and found a
page "updated partially 2007-02-17" which states that at the time they
were indeed green threads. [2]
[1] http://common-lisp.net/project/cmucl/doc/cmu-user/extensions.html#toc63
[2] http://c2.com/cgi/wiki?CommonLispThreads
Captain Obvious
Jan 21, 2012, 11:36:12 AM1/21/12
to
DH> If they were user-space ("green"), then I would expect them to be
DH> supported on all platforms.
User-space threads require cooperative schedulling which might be very
platform-specific.
For example, preemption can be implemented through a POSIX signal activated
by a timer (IIRC that's how it worked on CMUCL some time ago, at least that
was one of options).
If you want to preempt a thread which is blocked in I/O you must use
non-blocking I/O or aio.
Then you need to do something with the stack and CPU registers, which is
again platform-specific. And so on.
In theory POSIX supports pretty much all of this stuff in some way; but then
again, pthreads are native threads, so why don't they work on all platforms?
There is another kind of green threads which is related to
continuation-passing style. (I.e. run small blocks of computations in a
loop.)
It can be more platform agnostic but compiler has to be implemented around
this stuff and so must be all I/O subsystem. It's pretty much impossible to
add this stuff after you've made a single-threaded implementation. And I
imagine overhead is pretty significant.
My guess is that CMUCL has green threads of a first kind I've mentioned,
i.e. they have fat stack, fairly expensive schedulling and thus aren't like
Erlang threads, although they might be cheaper than fully native threads.
But it would be cool if some CMUCL developer will clarify this for us all.
DH> supported on all platforms.
User-space threads require cooperative schedulling which might be very
platform-specific.
For example, preemption can be implemented through a POSIX signal activated
by a timer (IIRC that's how it worked on CMUCL some time ago, at least that
was one of options).
If you want to preempt a thread which is blocked in I/O you must use
non-blocking I/O or aio.
Then you need to do something with the stack and CPU registers, which is
again platform-specific. And so on.
In theory POSIX supports pretty much all of this stuff in some way; but then
again, pthreads are native threads, so why don't they work on all platforms?
There is another kind of green threads which is related to
continuation-passing style. (I.e. run small blocks of computations in a
loop.)
It can be more platform agnostic but compiler has to be implemented around
this stuff and so must be all I/O subsystem. It's pretty much impossible to
add this stuff after you've made a single-threaded implementation. And I
imagine overhead is pretty significant.
My guess is that CMUCL has green threads of a first kind I've mentioned,
i.e. they have fat stack, fairly expensive schedulling and thus aren't like
Erlang threads, although they might be cheaper than fully native threads.
But it would be cool if some CMUCL developer will clarify this for us all.
Raymond Toy
Jan 21, 2012, 1:55:27 PM1/21/12
to
threads. Douglas Crosher would be the one who would know the fine details.
Yes, cmucl has user-space green threads. They're implemented by using
separate stacks for each thread. (For some reason switching threads
causes the stack to be copied instead of just switching the stack
pointer to the correct stack. I think.)
You can use sigalarm to switch tasks, but this doesn't work very well
because a lot of the code is not interrupt-safe. It's best to
cooperatively schedule threads. I think if a thread blocks, another
thread will be started, but I'm not sure about that either, and it might
only be for sockets.
Ray
hes selex
Jan 23, 2012, 5:50:14 AM1/23/12
to
Does cmucl support x86_64?
Raymond Toy
Jan 23, 2012, 10:11:36 PM1/23/12
to
On 1/23/12 2:50 AM, hes selex wrote:
> Does cmucl support x86_64?
>
Not yet. There is some preliminary work, but it doesn't work yet.
Ray
> Does cmucl support x86_64?
>
Not yet. There is some preliminary work, but it doesn't work yet.
Ray
0 new messages