[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Multiple Threads: Costs, Benefits
>>>>> "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
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"
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.