Re: some ideas for multithreading support

[Sam S. <sd...@gn...>]

Hi,

> * Bruno Haible <oe...@py...t> [2017-12-08 00:17:12 +0100]:
>
>    ...an error instead of a crash.

always.

> *Every object access* will have to be protected by taking a lock.

This may turn out to be far too expensive.
We might want to consider thread-local heap, similar to generational GC:
the most recent generation which is collected often may be thread-local
and require an explicit operation to share to a different thread and
require no lock for read/write.
on the other hand, we might want to share heap explicitly only: i.e.,
all heap is thread-local and there is an explicit (recursive/deep) copy
to shared (read-only?) heap.
I.e., to modify shared data, a thread copies it locally, modifies, and
copies back to shared heap.


> For example,
>
>   LISPFUNNR(car,1)
>   {
>     VALUES1(car(popSTACK()));
>   }
>
> will be rewritten to
>
>   LISPFUNNR(car,1)
>   {
>     var object argument = popSTACK();
>     RDLOCK(object);
>     var object result = car(argument);
>     RDUNLOCK(object);
>     VALUES1(result);
>   }

I think simultaneous reading is no problem.
I think writers should get an exclusive lock and readers a shared lock.

> RDLOCK(object) may signal an error:
>   "The object ~S is currently locked by thread ~S."

1. The error must have a "retry" restart.
2. The kind of lock (read/shared vs write/exclusive) should also be
specified.

> ...readdir_r instead of readdir.

note that readdir_r is deprecated.
https://www.gnu.org/software/libc/manual/html_node/Reading_002fClosing-Directory.html

> I don't know what the status on this task is, but I expect that this
> will severely limit the set of target platforms for multithreading to
> glibc and few other systems.

... which will severely limit the usability of multithreaded clisp.

> 3) Making use of standardized facilities
>
> I expect these facilities to be better optimized than what we could
> roll on our own. Therefore it will be interesting to see to which
> extent we can make use of them.

indeed!

> This too will limit the set of target platforms. In the end, I expect
> that only modern glibc, Windows, and macOS will be left as target
> platforms for multithreading.

which is sad because one of the salient features of clisp is
portability.

Thanks!

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504
http://steingoldpsychology.com http://www.childpsy.net
http://jij.org http://no2bds.org http://americancensorship.org
Which should be served first: the chicken salad or the egg salad?