Re: Are there plans for a multi-threaded Emacs?

[David Kastrup <dak@gnu.org>]

Martin Stjernholm <mast@lysator.liu.se> writes:

> David Kastrup <dak@gnu.org> wrote:
> 
> > It's not preemption, but preemption aware coding, and it does not
> > improve parallel execution but is a prerequisite for it.
> 
> Maybe we have a terminology problem here. I don't regard thread
> yields due to blocking operations or cooperative yielding as
> preemption.

The whole proposal was geared towards parallel execution of
computation-intensive tasks (like gnus summarizing and scoring) with
the editing foreground task.  If we are not talking about
multithreading, of course talking about preemption is idle.  But if
you remember, one topic that was brought up in this discussion was
hyperthreading.  Cooperative yielding can't make use of
hyperthreading.  Tasks that require cooperative yielding must not
share any resources with any other task in between synchronization
points (yield points, whatever).  So they can't make use of multiple
CPUs available.  For multiple CPUs, you need thread safe programming.

> Instead I reserve that term for uncooperative yielding when a time
> slice is up. It's perfectly fine to have several executing tasks in
> parallel without ever stopping any of them uncooperatively.

But it will not be able to make use of multiple CPUs.  And even with
cooperative multitasking you need separate stacks for several
resources, for every task, or you can only yield when at the top
level of bindings/stacks/whatever.

> >> Fine grained locking can, but it's hard to avoid making it too
> >> fine grained so that the locking itself becomes more time
> >> consuming than the speedup from the improved parallellism it
> >> achieves.
> >
> > For that reason it is important to have as few locks necessary as
> > possible.  And having to lock on the binding table would be
> > prohibitively expensive.
> 
> Another reason to have only a single interpreter lock and no
> preemption. It's hardly so expensive that it would take significant
> time compared to blocking operations, is it?

I don't see any usefulness at all.  Certainly every nontrivial task
will need to use the interpreter?  So where is the gain?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum