Hello,
we use the following to solve the problem of jiffies wraparound.
#define time_after(a,b) \
(typecheck(unsigned long, a) && \
typecheck(unsigned long, b) && \
((long)(b) - (long)(a) < 0))
#define time_before(a,b) time_after(b,a)
#define time_after_eq(a,b) \
(typecheck(unsigned long, a) && \
typecheck(unsigned long, b) && \
((long)(a) - (long)(b) >= 0))
#define time_before_eq(a,b) time_after_eq(b,a)
But I cannot understand it has some differences comparing with the
following code.
/* code 2*/
unsigned long timeout = jiffies + HZ/2;
if(timeout < jiffies)
{
/* not timeout...*/
}
else
{
/* timeout processing...*/
}
questions:
1.why the macros of time_after can solve the jiffies wraparound problem?
2.Is there any other possibilities for the "code 2" to overflow
except the jiffies overflow?
Any help will be preferred .
Thank you,
Yours.
As you mentioned the code for comparison:
> /* code 2*/
> unsigned long timeout = jiffies + HZ/2;
the code has no problem with jiffies wrapping around
as long as the values are compared in a right way.
For a 32 bit platform the counter wraps around only once every 50 day
when the value of HZ 1000. so if your code is prepared to face this event
it will work fine.
> 2.Is there any other possibilities for the "code 2" to overflow
> except the jiffies overflow?
No.
The better option would be to use the inline macros:
> #define time_after(a,b) \
> (typecheck(unsigned long, a) && \
> typecheck(unsigned long, b) && \
> ((long)(b) - (long)(a) < 0))
> #define time_before(a,b) time_after(b,a)
>
> #define time_after_eq(a,b) \
> (typecheck(unsigned long, a) && \
> typecheck(unsigned long, b) && \
> ((long)(a) - (long)(b) >= 0))
> #define time_before_eq(a,b) time_after_eq(b,a)
>
> But I cannot understand it has some differences comparing with the
> following code.
> 1.why the macros of time_after can solve the jiffies
> wraparound problem?
As it is clear that time_after evaluates true,
when a, as a snapshot of jiffies, represents a time after b,
These inlines deals with the timer wrapping correctly, because
if the timer wrap changes in the future , you won't have to alter the driver
code.
Typechecks are performed at the compiled time, that variables are of the
same type.
the code works by first converting the values to unsigned long, subtracting
them and then comparing the result.
so it is the safe way and most encoraged..
If you need to know the difference
between two instances of jiffies in a safe way, you can use the same trick:
diff = (long)t2 - (long)t1;.
regards
lk.
On Tuesday 27 December 2005 19:54, lk wrote:
> As you mentioned the code for comparison:
> > /* code 2*/
> > unsigned long timeout = jiffies + HZ/2;
>
> the code has no problem with jiffies wrapping around
> as long as the values are compared in a right way.
> For a 32 bit platform the counter wraps around only once every 50 day
> when the value of HZ 1000. so if your code is prepared to face this event
> it will work fine.
In 2.6 we actually roll over 5 minutes after starting (the jiffy counter is
set to about 5 minutes from roll over); that was put in on purpose to pick up
wraparound bugs easily.
Cheers,
Con
jeff shia <[email protected]> wrote:
> we use the following to solve the problem of jiffies wraparound.
> #define time_after(a,b) \
> (typecheck(unsigned long, a) && \
> typecheck(unsigned long, b) && \
> ((long)(b) - (long)(a) < 0))
> #define time_before(a,b) time_after(b,a)
[...]
> But I cannot understand it has some differences comparing with the
> following code.
>
> /* code 2*/
>
> unsigned long timeout = jiffies + HZ/2;
>
> if(timeout < jiffies)
> questions:
> 1.why the macros of time_after can solve the jiffies wraparound problem?
Because the overflows get compensated. It's a property of Galois Fields.
> 2.Is there any other possibilities for the "code 2" to overflow
> except the jiffies overflow?
timeout might overflow, too.
--
Ich danke GMX daf?r, die Verwendung meiner Adressen mittels per SPF
verbreiteten L?gen zu sabotieren.
On Tue, 2005-12-27 at 12:46 +0800, jeff shia wrote:
> 1.why the macros of time_after can solve the jiffies wraparound problem?
Basically it assumes that the two values you are comparing will never be
more than MAX_ULONG/2 apart. Which for jiffies means 270 some odd days
on 32-bit platforms.
--
Ben Collins <[email protected]>
Developer
Ubuntu Linux