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

[Martin Stjernholm <mast@lysator.liu.se>]

Ted Zlatanov <tzz@lifelogs.com> wrote:

> Not all threads need to be aware of each other.  Not all threads will
> compete for the same resources.

True, but these are arguments against a single lock. They have nothing
to do with preemption and cooperative yielding. Imho the advantages of
a single lock outweighs these.

> Not all threads, in a cooperative setup, will cooperate with each
> other due to programmer or design error.

Indeed. As I've said earlier, this is already the situation today.
Threads with cooperative yielding would provide a tool which I believe
makes it fairly simple to solve these cases. Some changes are
necessary, but otoh changes are necessary in the preemptive case too
since proper locking needs to be implemented.

> Also, I actually think it's easier to program for preemptive
> multithreading because you write thread-safe code instead of
> reengineering your code to fit the cooperative model.

Well, it's just as much reengineering to thread safe existing code as
to implement cooperative switching in it.

Anyway, it's not really an either-or situation. Thread tools like
mutexes are useful also in a cooperative environment. The difference
is that there's more control of where thread switches can take place
in the cooperative case. It's also possible to add a form like this:

    (auto-yield
      (while (big-task-not-finished)
        (work-on-big-task)))

`auto-yield' would instruct the elisp interpreter to yield
automatically inside the code block whenever it thinks it's time for
it. I.e. you'd get preemption inside that specific code block.

> Here's more examples: font-locking a buffer; reading or writing a
> file.

Reading or writing are blocking operations, so they would be executed
in parallel anyway.

Font locking is otoh cpu bound, but to get advantage of true
parallelism you'd need a situation where you do font locking at the
same time as something else that's cpu bound, e.g. Gnus scoring.
Otherwise it works fine to interrupt it to do display updates and so
on.

> Heavyweight threads are a problem because, as I mentioned already,
> Emacs is such a tightly coupled environment.  I think lightweight
> threads are better for performance.

Yes, I don't think it'd be useful very often either.

This is actually an argument against fine grained locking too: When
much code contend for the same resources and those are covered by many
small locks, much time will be spent in context switching due to
outlocking.