[Openmcl-devel] new 0.14 alpha binaries

Gary Byers gb at clozure.com
Tue Mar 18 16:58:18 PST 2003



On Tue, 18 Mar 2003, Sven Van Caekenberghe wrote:

> I justed tested the code you uploaded in testing: as far as the
> standard included portableaserve example goes, things seem to work
> fine. Tomorrow, I will test this combination with my web application.
>

I'm trying to work on a document explaining thread-related changes.
Since OpenMCL's multiprocessing API has never been documented, that's
likely to be a fairly large file (since I find that it's necessary
to explain how things used to work in order to explain the differences.)

Anyway, there's reason to believe that the paserve code that I uploaded
will fail under some conditions (and the reason(s) is/are instructive.)

One of those reasons is that critical sections of code (that require
exclusive access to data structures) are protected by:

(without-interrupts
   (do-things-requiring-exclusive-access))

In cooperatively-scheduled lisps, that's a common idiom (since WITHOUT-
INTERRUPTS had the side-effect of preventing the lisp scheduler from
running); it was a kind of shorthand for:

(with-appropriate-locking
  (do-things-requiring-exclusive-access))

and WITHOUT-INTERRUPTS was generally assumed to be cheaper.

Since there's no lisp scheduler anymore, WITHOUT-INTERRUPTS doesn't
prevent other threads from running; if there were such a thing as
WITH-OTHER-THREADS-SUSPENDED (I'm not saying ...), it would be a very
expensive, potentially dangerous thing whose casual use should be
discouraged.

To really be confident that we have exclusive access to shared
data structures, we need to use appropriate locking primitives.
Appropriate locking primitives generally exist in cooperatively
scheduled lisps as well (WITH-LOCK-HELD).

FWIW, OpenMCL 0.14 still contains cases where WITHOUT-INTERRUPTS is
(mis-)used this way.  WITHOUT-INTERRUPTS still exists and has its
uses, but a lot of the cases where it's still used in OpenMCL (and in
paserve) should be replaced with something more appropriate.

> Anyway, great work! Thanks a lot.

I want to finish the thread documentation, then make another pass
through the paserve sources to try and clean up some of these issues.
I think that it's possible to run paserve and OpenMCL under fairly
heavy loads without being bitten by these problems, but that's just
blind luck at this point.

>
> I took me many days to get the same things working in cmucl, in openmcl
> is just works out of the box. Is that the platform's touch ?
>
> Sven
>


_______________________________________________
Openmcl-devel mailing list
Openmcl-devel at clozure.com
http://clozure.com/cgi-bin/mailman/listinfo/openmcl-devel



More information about the Openmcl-devel mailing list