On Dec 16, 2005, at 2:04 PM, Peter Schuller wrote:
> I agree. I was mostly referring to a unified API for the usual
> primitives like mutexes, conditions and thread creation. While it is a
> no-brainer to write some conditional code for specific CL
> implementations when writing your application, it is something that
> should be unified from the start. A newbie should not have to know 6+
> CL implementations by heart to get such a basic thing right. ("Basic"
> in the context of concurrency.)
Concurrency is for better or worse something which has wide-reaching
implications on all aspects of a system, but is not standardized in
any reasonable format for CL. Just a quick example - should accessing
a lexical variable be atomic? What about from a closure? Is hash
table reading atomic? Writing? About the only standard I know of for
CL concurrency (CLIM 2's MP) does not cover these issues at all.
I guess my point is that concurrency goes beyond mutexes, conditions,
and thread creation. Those things are necessary to making concurrency
work. But making it work *right* is difficult in practice on one
platform.
It would be an interesting experiment to run Alan Shields' Araneida
benchmark against the five supported threaded Araneida backends. I
know that Gabor Melis has been assiduously working on making it
reliable on threaded SBCL. I would guess that most of those other
backends would have at least one stability issue too, judging from
the variety of issues that this benchmark has exposed on SBCL.
Perhaps the ABCL backend does not, though - Java takes a very heavy-
weight approach to object locking, and it's my guess that the threads
have been pounded on enough to work out any rare gc or interrupt-
safety kinks.
--
Brian Mastenbrook
[EMAIL PROTECTED]
http://brian.mastenbrook.net/
_______________________________________________
Gardeners mailing list
[email protected]
http://www.lispniks.com/mailman/listinfo/gardeners
