guile-devel
[Top][All Lists]
Advanced

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

Re: Serious bug inn GUILE rational handling


From: Han-Wen Nienhuys
Subject: Re: Serious bug inn GUILE rational handling
Date: Sun, 24 Dec 2006 13:32:29 +0100
User-agent: Thunderbird 1.5.0.8 (X11/20061107)

Han-Wen Nienhuys escreveu:
> Bill Schottstaedt escreveu:
>>> I have removed support for the reduced bit, and put the reduction in
>>> make_fraction.
>> I think it was intended that equal? would use scm_i_fraction_equalp
>> which reduces both arguments before checking equality.  So the
>> simplest fix would be to mask off the reduced bit in the cell type
>> in the check for cell type equality in scm_equalp.  I would hesitate
>> to remove support for this bit because it will mean you get gcd
>> on every integer divide!  The current system already slows Guile
> 
> I think thes best quick fix would be to put the bit into the 4th 
> double cell word. 

if the performance regression is serious, then we should do 
this for guile-1.8. 

where is the benchmark to measure this? 

>> down by about 10%.   On the race condition, my vage recollection
>> is that the "is this safe?" question was mine, and I hoped at that
>> time that someone who knew about such things would check it
>> out -- I believe (it's been a long time since I looked at this stuff)
>> that if that line is not safe, there are a lot more like it scattered
>> around Guile, so it's scarcely reason to jettison the entire thing.
> 
> In that case, we need to fix the more-like-it stuff.  Can you point out 
> some of those cases? 
> 
> I'm hesitant to put stuff like this in because 
> 
> 1. it _is_ a race condition

Note that this thing is also racing with any of the arithmetic instructions,
Suppose the reduce happens between
getting SCM_FRACTION_DENOMINATOR and SCM_FRACTION_NUMERATOR in scm_sum ?

Correct macros would extract both num and den atomically 
into temporary values.

> 2. if it is triggered, it will be next to impossible to reproduce. In
> effect this would lead to a once in a million inexplicable corruption.
> And that's really bad.
> 
> The correct solution would be a to use a lock-free instruction to 
> swap the old and reduced forms, but I'm not sure if we have those in 
> GUILE.

We seem to have something like it (FETCH_STORE) but no 
compare-exchange.

Glib's gatomic.c does have an enormous bunch of cmp & exch operations
in assembler for various platforms. 

Would it be an option to link GUILE to glib? 


-- 
 Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen





reply via email to

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