[r6rs-discuss] [Formal] SRFI-39 should be made an R6RS library

From: R. Kent Dybvig <dyb>
Date: Tue Feb 13 00:29:31 2007

> Hopefully you agree that all of the output should consist of some
> combination of "initial-x", "initial-y", "new-x", and "new-y"
> (rather than some thread printing "hello world"). (You might
> reasonably not agree even to that, of course!)

Or perhaps output like "initiinitiaal-xl\nnew--y\nx...".

> The stronger claim that I was making and that I think you are countering
> is that all threads should observe the changes in the same order.
> In other words, if any thread prints "initial-x" and "new-y" then
> no thread will print "new-x" and "initial-y" (and vice versa).
>
> You are suggesting it should be the other way around and that threads
> might disagree about in what order the two set!-s took effect.

That's certainly a possibility. In particular, I haven't seen
documentation to the effect that Posix threads, upon which Chez Scheme's
thread system is based, guarantees to the user and thus requires of the
implementation that memory writes migrate to all threads in the same
order.

But I was actually reacting to the first part of your original statement:

> If one has non-deterministic interrupts, and continuations, then one has
> threads. As with C's sequencing points, there are (only) specific
> points in the execution of a serial segment of Scheme code where a thread
> switch is permitted but that is a very fine-grained limitation.

I doubt an efficient multiprocessor implementation of Scheme can be had if
the language dictates the points at which a switch in this model can occur
to be anything like C's sequencing points, regardless of any other issues.

> 1. Are primitive operations atomic?

I would say no. Atomic primitive operations aren't particularly useful:
when multiple threads are manipulating a shared resource, more than one
operation is often involved, and the threads must synchronize at a higher
level anyway. Given this, it would be unfortunate if synchronization
overhead were also incurred at the lower level. It would be even more
unfortunate if the synchronization occurred when resources aren't actually
being shared.

> 2. Are primitive operations serializable?

If I understand what you mean, I would say no to this as well.

> (I withdraw any earlier suggestion that I have any strong opinion
> about the right answer to either question except to wonder aloud
> if a single language might have mechanisms that support each of:
>
> 1/2: no/no yes/no yes/yes
>
> in which case, the yes/yes answer for R6RS might be the
> conservative choice (with an eye towards adding other options
> later)?)

If R6RS were to include a thread mechanism, it seems to me that no/no
would be the conservative choice, since it would allow the widest range of
implementation choices and wouldn't give programmers guarantees that might
later be revoked. The draft R6RS doesn't mention anything about threads,
however, and I doubt that the final version will either. R6RS already
guarantees yes/yes, again if I understand your terminology, for the
nonthreaded programs it covers.

Kent
Received on Tue Feb 13 2007 - 00:29:16 UTC