Re: Concurrency via isolated process/thread

[Po Lu <luangruo@yahoo.com>]

Ihor Radchenko <yantar92@posteo.net> writes:

> I may be wrong, but from my previous experience with performance
> benchmarks, memory allocation often takes a significant fraction of CPU
> time. And memory allocation is a routine process on pretty much every
> iteration of CPU-intensive code.
>
> I am afraid that interlocking object allocation will practically create
> race condition between threads and make Emacs unresponsive.
>
> Or am I missing something?
> Is there a way to measure how much CPU time is spent allocating memory?

The detail of the interlocking can be increased if and when this is
demonstrated to be problematic.  Allocating individual Lisp objects
usually takes a short amount of time: even if no two threads can do so
at the same time, they will all have ample opportunities to run in
between consings.

> Would it be of interest to allow locking objects for read/write using
> semantics similar to `with-mutex'?

The problem is interlocking access to low level C state within objects
and not from Lisp code itself, and also avoiding constructs such as:

  CHECK_STRING (XCAR (foo));
  foo = XSTRING (XCAR (foo));

where the second load from XCAR (foo)->u.s.car might load a different
pointer from the one whose type was checked.