Multiple Threads: Costs, Benefits

[Marcus Daniels <marcus@sysc.pdx.edu>]

>>>>> "Don" == Don Cohen <donc@ISI.EDU> writes:

Don> In order to separate
Don> such a program into processes, you have to duplicate the
Don> information to be shared, and if both processes read and write
Don> that data, all the writes done by one have to be propagated to
Don> the other.  This can clearly get to be an expensive proposition,
Don> not only in execution resources, but also in programming effort.
Don> And even if you did send updates back and forth, you'd probably
Don> want multiple threads so that one could read the updates from
Don> other processes while another performed computations requested
Don> from its own input.

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.  A RPC object
library may or may not use threads for buffering -- that is another
matter.

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.

I glanced at the xview-input.lisp file from LispView.  It looks
to me like all it does is watch for input from the X server, and call
XView a C notify routine.  One idea would be to rewrite this code
in C, using the OS-level threads.  LispView isn't "pure Lisp"
anyway.

Don> Now the costs: It appears to me that it might (I guess only Bruno
Don> could be sure) be relatively easy, and impose few new
Don> constraints, to allow thread switching only between byte code
Don> instructions.  My guess is that these leave the system in a
Don> relatively consistent state.  The execution cost in the normal
Don> case would then involve at most one check per byte code
Don> instruction of whether it was time to worry about switching.
Don> This could certainly be done in one instruction.  It might be
Don> possible to reduce the overhead to near zero by using interrupts
Don> appropriately, e.g., to replace a branch address that normally
Don> leads to the top of the interpretation loop with one that leads
Don> to the thread checking code.

I'm not primarily concerned about the execution cost.  At worst,
there would be a build-time conditional compilation feature to make a
"with-threads" and "without-threads" CLISP.  The cost I speak of is
the development and maintenance cost.  Is this feature worth putting
time into compared to other things?  It really sounds like a big glob
of complexity that probably wouldn't get used much.  

Don> The cost of actually switching threads is fairly small in common
Don> lisp, since it's only the special bindings that have to be undone
Don> for one thread and restored for the other, and it's relatively
Don> rare to bind special variables.

I suppose one could initially ignore the problem of dynamic variables
and only worry about declared globals.