Subject: Re: [linux-audio-dev] cycle counter wrapping
From: Roger Larsson (roger.larsson_AT_skelleftea.mail.telia.com)
Date: ke loka 13 1999 - 17:22:19 EDT
Paul Barton-Davis wrote:
>
> >Only future will tell...
> >
> >But my point is that we should avoid code that can't handle
> >wraps correctly, it can be done without too much effort.
> >Like David's resyncronisation points (you do the resync when
> >no plugins run)
>
> alas, if it were that easy. but it isn't. by introducing this, you
> introduce the need for a lock around the timestamp code.
>
I wondered why, since it would only be one thread that writes to it.
But since it is a 'long long' the CPU would need two writes
and then another process might step in... or a rescheduling might
interfere.
So, yes I think this is a bigger problem than the wrap...
> when the cycle counter can overflow the hardware set aside for it by
> the chip manufacturer, there are much more serious problems in
> store for us.
>
And if they go for 128 bits we could handle it then by scaling.
But there should be a note about this in the comments...
> for now, i think we can take it as a given that the cycle counter, if
> used in full, and its associated data type (long long for gcc) will
> not wrap in any reasonable amount of time.
Shouldn't it be 'unsigned long long'?
/RogerL
--The Internet interprets Windows as damage, and routes around it.
Roger Larsson Skellefteċ Sweden
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:59 EST