R. Kent Dybvig wrote:
>> Threads are fine, regardless of implementation, if the effect is "as if"
>> we were witnessing an interrupt driven, serial execution of continuations.
>>
>
> That may be desirable for lightweight threads operating on a single
> processor, but the overhead of arranging this for a multiprocessor thread
> system would likely be prohibitive.
>
Hmm. Really? To make sure I understand and to share with the list
a reference to a classic paper, suppose that a program contains:
(define x 'initial-x)
(define y 'initial-y)
and one thread performs:
(set! x 'new-x)
while another thread performs:
(set! y 'new-y)
finally, other threads all do:
(write x) (newline) (write y)
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!)
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.
If that's what you mean, it would reflect the hardware design trend
towards weaker shared memory consistency guarantees in multiprocessor
systems. That in turn reflects the physical properties of signal
propagation at relativistic scales as described in the classic paper:
http://research.microsoft.com/users/lamport/pubs/pubs.html#mutual
"The Mutual Exclusion Problem -- Part I: A Theory of Interprocess
Communication, Part II: Statement and Solutions"
Perhaps the basic design choices for threads can (among many other
ways) be described as:
1. Are primitive operations atomic?
2. Are primitive operations serializable?
(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)?)
>
>> I think the big thing that is missing, to make things *not hideous*,
>> is (I hope I'm using the terminology correctly), delimited continuations.
>> In Guile Scheme (even absent true threads), I found it useful to
>> have a construct like:
>>
>> (call-with-one-shot-continuation (lambda (k) <body>))
>>
>
> These are simply "one-shot" continuations. Delimited continuations (also
> called partial continuations or subcontinuations) are something different.
>
I wrote poorly. I was thinking of Guile's feature for creating
"dynamic roots"
which I think probably are, essentially, delimited continuations but
I'll look further
into before abusing the terminology further.
-t
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.r6rs.org/pipermail/r6rs-discuss/attachments/20070212/d27e8148/attachment.htm
Received on Mon Feb 12 2007 - 22:18:28 UTC