Re: Some introductory docs about C level threading

[Marius Vollmer]

Doug Evans <address@hidden> writes:

> Marius Vollmer writes:
>  > Kevin Ryde <address@hidden> writes:
>  > 
>  > > You can force load/stores to be exactly as given using `volatile', [...]
>  > 
>  > How would that work exactly?  Can we flag each assignment operation as
>  > volatile, or would the SCM type need to be made volatile?  Would this
>  > be a reason to remove SCM_SMOB_OBJECT_LOC, for example, and to
>  > disallow pointers to SCM in general (since we must control all
>  > assignments)?
>
> I don't think GCC uses `volatile' to emit the memory barriers
> Ken is refering to.  Using `volatile' to solve this problem
> seems to me to be a non-starter.

There are two issues here: one is guaranteeing atomic access to SCM
values (SCM is a pointer type, i.e., a full word).  The other is
synchronizing memory (weekly ordered or not), so that all CPUs have a
coherent view of memory at a certain point in time.

We only need to solve the first issue for all accesses to SCM values
(I think).  The second issue might need to be addressed for a certain
small number of situations, but not in general for all accesses.

To put it differently, the question is what kind of memory model to
present to a multi-threaded Scheme program.

1) We must guarantee atomic accesses to values (where a 'value' is a
machine word) because a Scheme program must not crash because of
corrupted values, even when the threads of the program are not
properly synchronized.

2) We can get by with a weakly ordered memory model since out-of-order
stores do not crash the system.  They might cause the Scheme program
to be incorrect, but you need to properly synchronize it anyway.


As to 1), hopefully 'volatile' will guarantee atomic loads and stores.
Does it?  It will be enough if it just happens to work on the most
important SMP platforms.  (I.e., I could imagine that there is no way
to atomically read a 32-bit word on a CPU with a 16-bit bus, but I can
also imagine that these CPUs are not used in SMP systems any more that
we need to care about.)

As to 2), the Single Unix Specification says that a number of pthread
functions (and others) synchronize memory between threads, so that
using mutexes etc in the normal way will take care of memory
coherency, including weakly ordered memory.


Does this make sense?  I am still grabbling with the fundamentals, it
seems...