Re: multi-threaded Emacs

[Giuseppe Scrivano <gscrivano@gnu.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Yes, that makes sense.  Hopefully, most functions are "safe" in
> this respect.
>
> BTW, implementing "atomically" is not necessarily that hard.
>
> Of course, it can be implemented with an "optimistic locking" discipline
> where we track changes and undo them if the transaction aborts, but
> until we get there, there are meny much simpler implementations which
> will be useful.  A first implementation is
>
>   (defmacro atomically (&rest body)
>     `(let ((inhibit-thread-switch t))
>        ,@body))
>
> A better one, yet still trivial, is
>
>   (defconst the-lock (make-lock))
>   (defmacro atomically (&rest body)
>     `(progn
>        (lock-grab the-lock)
>        (unwind-protect
>            (progn ,@body)
>          (lock-release the-lock))))
>

IMHO the first is the better solution for a cooperative model.  There is
only a thread active at a time, introduce lock/unlock can easily cause
deadlocks, at least for the current threads scheduler implementation.
We will need lock/unlock when we will use parallel threads and we must
protect critical sections.

Personally, I would avoid to introduce `atomically' now with a
cooperative model but I prefer instead an explicit `yield'.  In this way
Elisp packages that use `yield' can benefit of threads and at the same
time it will not break old packages designed to work with a single
thread.  Using `atomically' and hidden `yield's all around can break old
packages that don't know about threads.

On the other hand, my wish is to have an Emacs with parallel threads
someday, surely it will needs explicit threads synchronization and
`atomically' must be introduced in any case.  It will break any Elisp
package that doesn't use where it is needed.  If we introduce it now,
Elisp packages will probably work well later too.

These are the advantages/disadvantages we will have choosing explicit
yield or using atomically to inhibit thread switches.  After all it is
just choose when "cause" problems in Elisp packages, now with
cooperative threads or later with parallel ones.

What do you think?  Do you want to have `atomically' now?

Regards,
Giuseppe