Re: [linux-audio-dev] cycle counter wrapping

New Message Reply About this list Date view Thread view Subject view Author view Other groups

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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:59 EST