[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Multithreading, again and again

From: Tom Tromey
Subject: Re: Multithreading, again and again
Date: Thu, 20 Oct 2011 11:07:33 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

>>>>> "Stefan" == Stefan Monnier <address@hidden> writes:

Tom> I think it is doable, given the context-switching constraints I
Tom> mentioned earlier.

Stefan> Yes a "simple" switch-on-yield should be sufficient (i.e. the old
Stefan> concurrency branch should be able to handle it), but that still means
Stefan> that solving such a problem requires handling interaction between the
Stefan> various kinds of Elisp variable bindings (thread-local, buffer-local,
Stefan> ...).


Tom> The long-term thing that would be cool is context-switching during QUIT.

Stefan> I'm not sure it would be significantly easier than true concurrency.

Tom> I don't think unconstrained context-switching is possible without some
Tom> drastic changes to the implementation.

Stefan> Why do you think so?

If you want all threads to run freely, then you have to make the Emacs C
code atomic with respect to any globally-visible change.  I just have no
confidence that it is this way right now.

Tom> My plan was to follow the Bordeaux threads API, more or less.

Stefan> I'm afraid that using locks is not going to work well for Elisp.
Stefan> I have much higher expectations for approaches based on yield
Stefan> (i.e. approaches which are inherently safe(r), with the main
Stefan> risk being lack of concurrency rather than race-conditions and
Stefan> corruption).

Tom> Can you expand on this?

Stefan> I'm not sure what kind of expansion you'd like to see: if you forget
Stefan> a lock you can get data corruption, whereas if you forget a yield you
Stefan> may just block a bit more often than desired (but still less often than
Stefan> in Emacs-23).

Ok, I thought by "yield" you were perhaps thinking of some kind of
co-routine-like model or something like that.  But if I read this
correctly you mean just a thread yield operation?  (Called
"thread-yield" on the concurrency-2 branch...)

I think cooperativeness doesn't really eliminate the need for locks,
especially because I plan to allow context switches at I/O (and some
other blocking operations, like mutex acquisition).

Of course, the situation is really a bit like process filters.  Probably
a lot of actually existing Emacs Lisp code will run fine with multiple
threads, even without any locking whatsoever.  That will remain true for
some time: either multiple threads will be due to multiple keyboards (in
which case users probably won't be surprised by odd behavior they caused
themselves) or multiple threads will be from new code using the new
feature, which generally won't be written to randomly stomp all over


reply via email to

[Prev in Thread] Current Thread [Next in Thread]