Re: scm_i_fraction_reduce thread safety

[Carl Witty <cwitty@newtonlabs.com>]

On Tue, 2004-01-20 at 16:00, Marius Vollmer wrote:
> Kevin Ryde <user42@zip.com.au> writes:
> > Yep, though it seems a shame the accessors have to be slowed down just
> > so printing and equality can write back.
> 
> Is that slow down significant?  The logic could be like
> 
>   if fraction is not reduced:
>     lock
>     if fraction is not reduced:
>       reduce it
>     unlock
>   read it
> 
> So in the common case of a reduced fraction, no locks would be
> necessary.  (This works since a fraction can never go from reduced to
> unreduced.)

I'm afraid this doesn't work.  The idiom is known as "double-checked
locking"; see
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
for an explanation of why it doesn't work.  (Briefly: the "reduce it"
code will do something like the following: write numerator, write
denominator, write "fraction is reduced" marker.  The compiler is
allowed to re-order these writes, so the "fraction is reduced" marker is
written before the numerator and denominator.  Even if it does not, on a
multi-processor machine, the memory system may reorder these writes
between processors, unless you put (expensive and non-portable) "memory
barrier" instructions in the appropriate places.)

Read the web page linked above before you suggest ways to fix this.

Carl Witty




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