Re: Multithreading CLISP

[Bruno H. <br...@cl...>]

Sam wrote:
> note that the old suggestion "just be aggressive and lock all arguments
> of each function" (and maybe unlock later) does not really help because
> locking an object does not lock its referents, and recursive locking
> is inefficient.

Yes, and furthermore Lisp is highly recursive and open, which makes it
hard to impose locking restrictions and to define a lock hierarchy.

Let's take for example a hash-table variant in which the gethash function
takes a default-producing function as argument: (gethash obj ht default-fn).
Shall the hash table be locked while the default-fn is executed? If yes,
you get into a deadlock easily. If no, then what happens if after the
return from the default-fn the hash table finds that a value has been set
for the given key while the default-fn was executing? You'll probably
ignore the default-fn's value in this case and return the just-stored
value. But you see that already in this simple case, you have to make
worrisome decisions.

> This has already been done by other implementors, both free (CMUCL/SBCL)
> and proprietary (ACL, LW).  we can look at their docs.

CMUCL and SBCL have no usable docs about multithreading. ACL and LW may
look better.

> Actually, ACL people have been very helpful on c.l.l.
> I see nothing wrong in learning from them.

Sure, I didn't mean to exclude them. Only they probably don't have a lot of
time for discussions.

Bruno