Re: Multithreading?

[Sam S. <sd...@gn...>]

> * In message <Pine.LNX.4.21.0301061503180.8026-100000@tatara-ba>
> * On the subject of "Re: Multithreading?"
> * Sent on Mon, 6 Jan 2003 15:48:37 -0500 (EST)
> * Honorable Dan Knapp <da...@ch...> writes:
>
>   (Please let me know whether you prefer to receive a private copy of
> these messages in addition to the one sent through the list!  I
> noticed that the sourceforge servers take a while to forward, so I
> Cc:ed it...)

I am neutral about it.  I supply a copy because that's what emacs/gnus
does when I hit F.  you can do as you please.  I do read this list.

> > Allegro, CMUCL, LispWorks &c all call them processes.
> > The reason is that most of the older CLs do not use OS threads.
> > I am not sure whether it would be better to break away from the
> > existing terminology and use the word THREAD (as Corman Lisp does).
> 
>   A fair concern, you already have my opinion.  In general I
> think old terminology should be changed freely as it becomes
> inappropriate, unless there is a great body of legacy code.

if you do the coding, you get to pick the naming. :-)

> > a concurrent garbage collector will make it necessary to implement read
> > barriers, i.e., looking inside an object would require a check.
> 
>   ... You're right; since there has to be some care taken on access
> anyway, using the foreign heap doesn't buy much.
> 
>   Wouldn't a write barrier be more efficient?

of course.  but it is not enough if we have a concurrent garbage collector.

> > well, don't you think that
> > 
> >         (defstruct s a)
> >         (setq x (make-s))
> >         ...
> >         (eq (setf (s-a x) 'foo) 'foo)
> > 
> > should evaluate to T?
> > you are right, we are allowed to get away with not maintaining this,
> > but is it a good idea?
> 
>   No!  I don't think that's expected or desireable behaviour.
> 
>   I assume what you mean is:
> 
>   (setf (s-a x) 'foo)
>   (eq (s-a x) 'foo)
> 
> ... which is not the same as your version, because (setf)
> expansions are permitted to simply return the value they are
> passed, rather than actually looking it up again.  A brief
> experiment with (macroexpand-1 '(setf ...)) suggests that they
> usually do, too.

my bad.

>   Even with per-object mutexes the result wouldn't necessarily be
> T, because the lock would (or should) be released after the
> (setf) does its access, and re-acquired before the (eq) does its.
> 
>   When it's important that the result be T, the correct way to
> write the code would be:
> 
>   (with-lock some-lock
>     (setf (s-a x) 'foo)
>     (eq (s-a x) 'foo))

this will work only if every other thread uses some-lock when writing
to x.

but this is not quite what I was talking about.

suppose we have a CLOS object O.  we do

        (setf (slot-value O 'slot-name) 'foo)

this means that we check that O has a slot named slot-name and then set
it to 'foo.
if another thread at the same time changes class of O and slot named
slot-name disappears, we are in trouble (segfault).

this is obviously a user's fault, but WINBNI if we prevented that by
adding a mutex to O?

> Certainly it is very much against the spirit of Lisp that, if the
> application programmer does things wrong, the implementation will
> crash.

that's exactly my point!

>   My view on this is that unfortunately, the abstraction of
> threading cannot be implemented safely without imposing
> unacceptable performance penalties, in much the same way
> that pointer arithmetic cannot.  If you wish to maintain safety,
> you must use a different abstraction which provides similar
> functionality (though it may be implemented on the same
> primitives).  In a sense, dynamically-typed vectors are what
> Lisp uses instead of pointer arithmetic.

yes, unfortunately you are right.

>   One alternative to threading would be a transaction-safe,
> shared, persistent, transparent object store; this is much
> like an object-oriented database.  In fact, I'm very much
> in favor of one, but it would be a great deal of work;
> whereas threading is fairly simple to implement.
> Pragmatically, it's pretty clear that it's better to
> provide threading now, and take it out if and when we
> implement transactions.

I think you are overly optimistic as to the simplicity of MT.


-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
I'm out of my mind, but feel free to leave a message...