Re: What are the arguments in favor of delay/force in eval.c?

[Rob Browning <rlb@defaultvalue.org>]

Kevin Ryde <user42@zip.com.au> writes:

> (Speaking of which, I'd thought before that once a promise is forced
> it shouldn't need a mutex any more, which would save a bit of time and
> space.)

I suppse it might, though you'd have to be very careful with the
coding.  i.e. (offhand) you would probably have to do something like
this:

  SCM mutex = SCM_PROMISE_MUTEX(p);  // assume atomic copy
  if(scm_is_null(mutex))
    result = SCM_PROMISE_DATA(p);  // [1]
  else
  {
    scm_lock_mutex(mutex);
    if(scm_is_null(SCM_PROMISE_MUTEX(p))  // must check again after lock
    {
      // someone was already evaluating when we started
      // (and must have finished now)
      result = SCM_PROMISE_DATA(p);
    }
    else
    {
      SCM ans = scm_call_0(SCM_PROMISE_DATA (ans));
      SCM_SET_PROMISE_DATA(p, ans);
      SCM_SET_PROMISE_MUTEX(p, SCM_BOOL_F) // (do last to avoid race at [1])
      result = SCM_PROMISE_DATA(p);
    } 
    scm_unlock_mutex(mutex);
  }

Note that this wouldn't be safe if the initial mutex assignment might
copy a value that has been half filled by some other thread.

Of course, if we're interested in srfi-45, then it would require
somewhat more...

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel