Am Sa., 11. März 2023 um 20:29 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>
> Gauche has been mutexing realization of a promise, but srfi-226 is the right thing; evaluation of the body may communicate to another thread that may take the value of the promise.  Current Gauche deadlocks in that case.
>
> By the way, in the reference implementation, 'force' has this code:
>
>    (if (promise-done? p)
>        ((promise-thunk p))
>        (call-with-immediate-continuation-mark ....))
>
> And:
>
>    (promise-lock! p)
>    ...
>    (promise-done?-set! p (promise-done? q))
>    (promise-thunk-set! p (promise-thunk q)))
>    ...
>    (promise-unlock! p)
>
> First I thought you need to lock promise to check promise-done? and retrieve promise-thunk, otherwise you may read the old value of promise-thunk and reevaluate  the body.  However, it is allowed that the body is evaluated multiple times, it's ok.  Am I understanding it right?

The body is allowed to be evaluated multiple times (if a promise is
concurrently forced). Still, the observed values of the forced promise
should come from the same evaluation of the body.  So in the second
part of the quoted code, the thunk should be set first and then the
done? flag to eliminate the race condition.  (An atomic fence (see
SRFI 230) may be needed by some implementations so that the observed
mutation order is the same in all threads.)

Do you see a new problem arising with reordering the two set!s?

>
>
>
>
>
>
>
>
>
>
> On Sat, Mar 11, 2023 at 3:02 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>>
>> Am Sa., 11. März 2023 um 11:11 Uhr schrieb Shiro Kawai <xxxxxx@gmail.com>:
>> >
>> > From the srfi text, it is allowed that the delay's body to be evaluated by more than one thread simultaneously; only that the result of force is the result of the first delivered result.  Am I right?
>>
>> Indeed.  This is analogous to promises being forced while their "body"
>> is evaluated, even in the same thread.
>>
>> >