Re: scm_i_fraction_reduce thread safety

[Kevin Ryde <user42@zip.com.au>]

Richard Todd <richardt@vzavenue.net> writes:
>
> 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.

Or don't mutate, except possibly under gc.

> 2) Aren't (numerator frac) and (denominator frac) themselves other
> examples of would-be readers that might have to 'write back' in this
> setup?

Yep.

> 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?

Well, locks will slow down accesses, but the question of when to do
gcds really depends on num+den at risk of growing more or less
unboundedly and on the way gcd is O(N^2) so much better to do on
smaller operands where possible (assuming a reduction will in fact be
wanted at some point, which would not be the case say if rounding to
an int or float at the end).


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