As far as the write-write order is preserved, reordering eliminates the race and I don't see new problems.
On Sun, Mar 12, 2023 at 5:59 AM Marc Nieper-Wißkirchen < marc.nie...@gmail.com> wrote: > Am Sa., 11. März 2023 um 20:29 Uhr schrieb Shiro Kawai < > shiro.ka...@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 < > marc.nie...@gmail.com> wrote: > >> > >> Am Sa., 11. März 2023 um 11:11 Uhr schrieb Shiro Kawai < > shiro.ka...@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. > >> > >> > >
