[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MIT-Scheme-devel] Symmetric MultiProcessing

From: Matt Birkholz
Subject: Re: [MIT-Scheme-devel] Symmetric MultiProcessing
Date: Sun, 3 Jan 2016 12:48:48 -0700

> From: Taylor R Campbell <address@hidden>
> Date: Thu, 20 Aug 2015 16:57:25 +0000
> [...]
> The safe way to do this is:
> (let ((p (cons item constant-space-queue)))
>   (membar-write)
>   (set! constant-space-queue p))
> (let ((queue constant-space-queue))
>   (membar-read)
>   (if (and (not (eq? '() queue))
>            (not (object-constant? queue)))
> (car queue) and use it...))
> [...]
> A little more broadly, my point is that if you're going to skip a
> lock, then the burden is on you to prove that it's safe, either by
> inserting appropriate memory barriers or showing a convincing argument
> that they're not necessary.

I think I see now.  Thanks for the explanation.  I actually just
locked up writers.  I WOULD like to accommodate multi-core Alphas and
other unicorns.  To make this accommodation I just need to add a
"matching" membar-read to the readers, and a membar-write to the
constructors?  The writers, using pthread_mutex_unlock, are already
flushing cache?  Thus the incoherent core will invalidate its cache
and subsequently read new values recently written by another core that
flushed its incoherent cache with a "matching" membar-write?

6 or 8 web sites and a chapter or three from the IA-32/64 architecture
manual and I'm only sure that... unicorns are rather magical.

I was just trying to banish without-interrupts so I can multi-process
on an IA-32/64.  The burden of a serious review for "naivete" in the
runtime system I'm just going to leave where you dropped it.

Actually I tried to make another review of all 26 or so files (those
that had fiddled the interrupt mask) but sailed quickly into a raft
questions I think the owner of a unicorn might want to answer.

That may be ME next month (given a unicorn of the ARMv8 running Ubuntu
variety).  Anticipating that possibility, I expect it would be nice to
audit the code with a firm set of rules, as you began, but I would
like to pursue that in another thread, and finish addressing your
concerns here.

> As long as that's an intentional change that has only trivial adverse
> consequences, that's OK.  But I wonder how much space it takes up on,
> e.g., i386.

In i386/ 556 words.  I got that from evaluating

        (* 2 (length constant-space-queue))

in the (runtime garbage-collector) package.  Constant space itself is
11.8 MiW (mebi-words [retch]) according to


so... ya, totally worth it.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]