On Thu, Jun 7, 2012 at 11:31 AM, Mark H Weaver <mhw@netris.org> wrote:
> John Cowan <cowan@mercury.ccil.org> writes:
>
>> Duncan Steele scripsit:
>>>
>>> I think it would be great for there to be a way to give an (optional)
>>> hint to the interpreter/compiler to evaluate (delay ) ed expressions
>>> in a background thread.  I assume that the lion's share of threading
>>> support will be in R7RS-large, but with the trend of rapidly increasing
>>> core counts I think that parallelism in some form must be tackled by
>>> any serious language at the language level, and not delegated to its
>>> standard library.
>>
>> It seems clear that having `delay` spawn a background thread is consistent
>> with the R5RS/R7RS definition of `delay`, so I have added the following
>> editorial remark:
>>
>> # This behavior may be implemented in a variety of ways,
>> # including the return of a thunk which `force` will evaluate
>> # to the creation of a background thread to do the computation.
>
> This has the potential to break existing code for at least two reasons:
>
> (1) It means that the delayed expression may be evaluated even if the
> promise is never forced.  Therefore, programs which are designed with
> the assumption that unforced promises will never be evaluated will do a
> lot of unnecessary computation and possibly become unusable.
>
> (2) It means that if the delayed expression mutates any shared state,
> thread synchronization primitives will now be needed.  Since such
> primitives are not present in R7RS-small, it will be impossible to use
> 'delay' and 'force' in a portable R7RS-small program.  Even if such
> primitives are added, it means that portable programs will need to
> assume that such (very expensive) synchronization primitives must be
> used.

Actually, I can't parse John's note.  It sounds like the thread
would be created only on "force"?  That would not have these
problems, though I'm not sure what the benefit would be.

If the compiler could prove that the delayed expression were
referentially transparent and either independent of dynamic
extent or guaranteed to be forced in a known extent (e.g. the
same one as the promise creation) then it would be possible
to run it pre-force in a separate thread (with some limits to prevent
infinite thread creation).  The same logic could be applied to
run e.g. map in multiple threads - even trivially on top of this
delay:

  (define (maybe-concurrent-map proc ls . lol)
    (map force
         (apply map (lambda args (delay (apply map proc args))) ls lol))

But this is the work of a smart compiler working within the
existing definition of delay/force, so it doesn't bear mentioning
in the standard.

I agree with Aaron that programmers should explicitly use
something like futures for this case, and look forward to
them in WG2.

--
Alex

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports