guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Rob Browning
Subject: Re: What are the arguments in favor of delay/force in eval.c?
Date: Wed, 07 Dec 2005 14:47:00 -0800
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

Kevin Ryde <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]