guile-devel
[Top][All Lists]
Advanced

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

Re: scm_i_fraction_reduce thread safety


From: Carl Witty
Subject: Re: scm_i_fraction_reduce thread safety
Date: 20 Jan 2004 19:11:19 -0800

On Tue, 2004-01-20 at 16:00, Marius Vollmer wrote:
> Kevin Ryde <address@hidden> 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






reply via email to

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