Re: scm_i_fraction_reduce thread safety

[Richard Todd]

Kevin Ryde wrote:

> Marius Vollmer <address@hidden> writes:
>
> > User code should only use scm_numerator and scm_denominator to access
> > parts of the fraction object and those functions will first reduce the
> > fraction (in a thread safe way).  Wouldn't that be enough?
>
>
> Yep, though it seems a shame the accessors have to be slowed down just
> so printing and equality can write back.

I may not fully understand this, but after reading through the messages 
on the list, and having been awake for 36 hours, I can't help but think 
at least two things:

1) If you are worried about thread safety, the most fool-proof C 
interface probably does not allow separate access to numerator and 
denominator, since they need to be read in one atomic operation to 
ensure consistent results in the face of other mutating code.

2) Aren't (numerator frac) and (denominator frac) themselves other 
examples of would-be readers that might have to 'write back' in this 
setup?  According to r5rs they return the reduced value.

For the speed issue in general, doesn't it come down to whether the 
extra gcd()s of eager reduction would be cheaper than the mutex_lock()s 
of lazy reduction?  If I'm thinking straight, the mutex only seems 
necessary if SCM_FRACTION_REDUCED(n) == #f, so as long as you don't 
mutate/reduce/mutate/reduce in a tight loop, there may not be much 
mutexing at all.  Seems like it could be tried both ways.

Richard