[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Multiple Threads: Costs, Benefits
- To: clisp-list <clisp-list@ma2s2.mathematik.uni-karlsruhe.de>
- Subject: Re: Multiple Threads: Costs, Benefits
- From: Don Cohen <donc@ISI.EDU>
- Date: Mon, 18 Sep 95 09:36:47 PDT
- In-reply-to: Your message of "Sat, 16 Sep 95 21:46:02 +0200." <199509161546.PAA04941@sayre.sysc.pdx.edu>
Marcus:
Whatever I would need threads for would be performance
(e.g. preprocessing data); otherwise I'd use IPC...
I guess this has to do with your uses of lisp.
In hope of convincing (at least some of) the skeptics, I describe one
below.I invite other people who want multiple processes to describe
their applications.
I have what amounts to a database in a lisp virtual memory.
In the same way that databases try to offer shared access to many
users I want to offer shared access to many processes, which may
represent many users, or just different things being done by one
user. All the usual problems of locking arise, of course.
The point is that I want the database accesses and updates to all
occur in the same shared memory lisp process, rather than trying to
ship the relevant data to the processes that need it and ship the
updates back. Shipping the relevant data in most cases would be
more expensive than executing the query. Now the processes that
share the database might themselves be either lisp threads in the
database process or separate processes, but even if they are separate
processes, they'll send queries and updates to the database process,
and those requests must be handled "in parallel", i.e., we don't want
every process that represents a person asking a simple question to have
to wait for another process that represents some long computation, just
because the long computation started before the short request arrived.
I also do not want to try to rewrite all the code that deals with the
database to try to identify places where it would be safe to switch
processes, and try to ensure that these places arise with sufficient
frequency. This would be a very complex task, very likely to fail,
and very difficult to maintain.
Marcus:
I don't have any technical arguments I care about. I just don't want
to divert my time away from things that I *do* care about.
Of course, if someone made the winning effort to implement this
I would help to integrate it. It is just that, personally, I'm
indifferent about it.
I think this is entirely reasonable. I was not asking YOU to do it.
I was hoping to find other people who really want it and have the
ability to contribute to the effort, and find some way to coordinate
their efforts to actually achieve something.
I haven't heard any concrete offers yet, but still hope to.