Re: Some introductory docs about C level threading

[Marius Vollmer]

Ken Raeburn <address@hidden> writes:

>>    It is safe to use `SCM_CAR' and `SCM_CDR' on the local variable LIST
>> once it is known that the variable contains a pair.  The contents of
>> the pair might change spontaneously, but it will always stay a valid
>> pair (and a local variable will of course not spontaneously point to a
>> different Scheme object).
>
> But is it guaranteed that, without locking, SCM_CAR and SCM_CDR will
> always return the "before" or "after" values while another thread is
> modifying them, and not some corrupted intermediate form?  Given
> typical data alignment and access, and hardware memory management
> techniques, and the small size of a SCM value, I'm not aware of a
> situation where it would be at all likely to happen, but I'm also not
> aware of any guarantee that it won't.

I'd say we pretty much have to assume this behavior, even without a
guarantee, when we want to have truly concurrent threads.  The
alternative would be to only allow one thread to access the heap at
any one time.

I am seriously willing to consider this alternative, but right now,
let's see how far we can get with concurrent threads.

> Though, even without weird memory management issues, consider:
>    SCM_SETCAR(x, SCM_I_MAKINUM(i >> 2))    i some external int var
>   -> (....x)[0] = ((... i >> 2) << 2 + scm_tc2_int)
>   -> copy i, masking off bottom two bits, into target location; then
> add in scm_tc2_int
>
> If SCM_CAR(x) is read at just the wrong time, the tag bits might not
> be correct.

Yes, this is a real issue (which I wasn't aware of previously).  More
about this further down in this thread.

> It may also be the case that if both the car and cdr of the pair (or
> indeed, any two separate locations) are modified in one thread and
> read in another, the memory accesses could be reordered (by the
> compiler, or even by the CPU these days) such that the read-back
> contents of the pair don't seem to match the "before" or "after"
> values or even the expected intermediate state where the first-listed
> modification has been done but the second has not.

This behavior can be allowed, as Guile only has to guarantees that a
single SCM is modified atomically.  Thus, the car and cdr will always
be a valid SCM value, but they might be totally arbitrary and your
code must make no assumptions about it.

In order to use a pair from two threads meaningfully, you need to put
in some synchronization, such as a mutex.  But this is left to the
upper layers of the program, where these issues can be solved.

> If someone's got lots more experience with multithreaded systems and
> wants to say I'm wrong, great.  I've been thinking about this a bit
> lately, trying to make a pile of code thread-safe at work, but I'm
> mostly coming at it from a theoretical perspective.

Me too. ;-)  (My pile of code is actually Guile itself.)