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

[Martin Stjernholm]

Ted Zlatanov <address@hidden> wrote:

> What I proposed is that *all* functions start with the "synchronous"
> atribute.  This would apply to primitives as well.
>
> Then, they would be gradually rewritten.  For instance, a thread-safe
> setq would act just like the regular setq, but it would lock its
> arguments with semaphores before modifying them.  The thread-safe
> setq can then be marked "asynchronous."

What about simply having a single mutex for everything? It's
essentially always held, and a thread only relinquishes it to do
blocking operations. Immediately afterwards it reacquires the lock.

This way Emacs is still effectively single threaded (in the sense that
only one thread runs at a time) but it is possible to use the
threading paradigm to do blocking operations. It's comparatively easy
to implement since all data access still goes on as usual. It's
necessary to make the C level thread safe only in the small regions
where the lock is released.

I take it this would essentially be the same as your starting point,
where all functions are synchronous - nothing runs at the same time as
anything else. There are however only small benefits to go further:

o  To be able to run several threads simultaneously in multicpu or
   hyperthreaded systems.
o  To get OS level preemption between threads.

Preemption can be simulated on the elisp level by making sure that no
significant amount of code gets to run without relinquishing the lock.
I.e. there is a function that gets called regularly that only releases
the lock, yields (if the thread implementation supports it) and then
takes the lock again.

Another possibility is to do no preemption at all, and instead
introduce an elisp function `yield' that does the above. CPU bound
code should call it explicitly every once in a while. That has the
nice property that other elisp code does not have to use locks to
avoid preemption in sensitive areas. This means "old fashioned"
cooperative multitasking, and malfunctioning code can still lock up
everything, but that's not any worse than the situation today so I
don't regard it as a significant problem.

I see these benefits with this model compared to a "fully"
multithreaded variant:

o  Fairly small changes in the C code.
o  No significant change in the elisp execution model, at least not if
   preemption is avoided.
o  Little overhead in locking - there's no fine grained locking on
   individual data structures.