Re: Multiple Threads: Costs, Benefits

[Don Cohen <donc@ISI.EDU>]

Marcus:
 As a practical matter, in the world of object-oriented applications,
 I don't believe that this notion of syncronizing data is good
 example of where threads are crucial.  I mean, you've got an object
 running in process A, and a object running in process B.  Whether
 they are written in C++ or CLOS they ought to use accessors for
 modifying data.  Even in the Windows(TM) world there exists a relatively
 straightforward way to redirect such calls over RPC.
I don't see what OO-ness has to do with it.  You're suggesting that
data be partitioned (so it belongs to one process or another) and that
interprocess communication be used instead of shared memory.
I think the important point is that this communication is not free.
It may represent a trivial overhead if the communication occurs at a
high enough level (= low bandwidth), but if you want to do the equivalent
of a structure access, the overhead is very significant.  It can be a lot
of work to change a program written naturally to do a lot of access of the 
second sort to a program that does the first sort.
Another programming problem is that all the things that we tend to think
of as objects in lisp compared by EQ now have to be given IDs in order
to refer to them from another process - that also costs space, time and 
programming effort.

Marcus

 Just because CLISP lacks Lispy multiple threads, doesn't mean it isn't
 possible to have multiple threads. There exists a CL music package
 which uses threads on NEXTSTEP (via a few C functions and the FFI).
 I suspect most of the applications of threads are so fine grained
 that this approach is sensible.

It looks like you're now agreeing that it makes sense to use threads
(processes sharing memory), but that whatever you need to do with them
can be done in C.  I guess you could do everything in C.  I won't try
to convince readers in this mailing list that there are reasons to use
lisp instead.  What is it about applications where threads make sense
that also makes them more appropriate to do in C?  I'm not sure what
you mean by "fine grained".  Do you mean that it's necessary to switch
threads at high frequency?  The frequency is related to how long you're
willing to wait for the process in the biggest hurry.  Even if that's
not a very short time, it may make much more sense to use threads.

Marcus:
 I'm not primarily concerned about the execution cost...
 The cost I speak of is the development and maintenance cost.
I tried to address both problems.
I suggested that this feature might not interact much with other
design decisions (if we only switch threads between byte code instructions)
so the development (and maintenance) cost might be small.
Of course, my guess could be wrong.  I'd be interested if anyone sees
why it should be.

Marcus:
  I suppose one could initially ignore the problem of dynamic variables
  and only worry about declared globals.
I don't see any point in trying so separate global from other special
variables.  I also don't see why this should be a concern to the
implementation.  Every thread starts in the global environment, and
it can rebind whatever specials it wants to.