Hi,
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
> Hmm, I cannot think of more ways to specify a timeout than how
> long I want to wait (relative) or until when (absolute) and which
> is the reference clock. And they don't seem broken to me, common
> sense, in any case. Do you have any examples?
You still didn't explain what's the point in choosing different clock
sources for a _timeout_.
> Different versions of the same function that do relative, absolute.
> If I keep going that way, the reason becomes:
>
> sys_mutex_lock
> sys_mutex_lock_timed_relative_clock_realtime
> sys_mutex_lock_timed_absolute_clock_realtime
> sys_mutex_lock_timed_relative_clock_monotonic
> sys_mutex_lock_timed_absolute_clock_monotonic
> sys_mutex_lock_timed_relative_clock_monotonic_highres
> sys_mutex_lock_timed_absolute_clock_monotonic_highres
Hiding it behind an API makes it better?
You didn't answer my other question, let's assume we add such a timeout
structure, what's wrong with converting it to kernel time (which would
automatically validate it).
bye, Roman
On Thu, Sep 01, 2005 at 11:19:51AM +0200, Roman Zippel wrote:
> You still didn't explain what's the point in choosing
> different clock sources for a _timeout_.
Well, if CLOCK_REALTIME is set forward by a minute,
timers & timeout specified against that clock will expire
a minute earlier than expected. That doesn't happen with
CLOCK_MONOTONIC. Applications should have the ability
to select what they want to happen in this case (ie,
whether the timeout/timer has to happen at a particular
wall-clock time, say 2pm, or if the interval aspects of
the timer/timeout are more important). Applications
get this if they have the ability to specify the clock
their timer or timeout is specified against.
Also ..... (I am going off the deep end here) .....
The purpose of CLOCK_REALTIME is to track wall clock time.
That means it can be speed up, slowed down, or even be
force-fed a new time to make it match.
The purpose of CLOCK_MONOTONIC is to provide an even,
unchanging progression of advancing time. That is, any two
intervals on this time-line of the same measured length
actually represent, as close as possible, the same length
of time.
CLOCK_MONOTONIC should get adjustments only to bring its
frequency back into line (but currently gets more than this
in Linux). CLOCK_REALTIME should and does get adjustments
for frequency and then gets further, temporary speedups
or slowdown to bring its absolute value back into line.
Note that there is no need for the two clocks to track each
other in any way, as Linux currently goes to lengths to do.
I know Linux does not implement the above definition
of CLOCK_MONOTONIC; however, I would like an interface
where when, if the day comes time is properly handled,
applications can take advantage of it.
Joe
Hi,
On Thu, 1 Sep 2005, Joe Korty wrote:
> On Thu, Sep 01, 2005 at 11:19:51AM +0200, Roman Zippel wrote:
>
> > You still didn't explain what's the point in choosing
> > different clock sources for a _timeout_.
>
> Well, if CLOCK_REALTIME is set forward by a minute,
> timers & timeout specified against that clock will expire
> a minute earlier than expected.
That just rather suggests that the pthread API is broken as usual.
(No other possible user was mentioned so far.)
> That doesn't happen with
> CLOCK_MONOTONIC. Applications should have the ability
> to select what they want to happen in this case (ie,
> whether the timeout/timer has to happen at a particular
> wall-clock time, say 2pm, or if the interval aspects of
> the timer/timeout are more important). Applications
> get this if they have the ability to specify the clock
> their timer or timeout is specified against.
So setup a timer that goes off at that time and interrupts the operation.
There is no need to overload the operation itself with an overly complex
timeout specification.
> The purpose of CLOCK_MONOTONIC is to provide an even,
> unchanging progression of advancing time. That is, any two
> intervals on this time-line of the same measured length
> actually represent, as close as possible, the same length
> of time.
>
> CLOCK_MONOTONIC should get adjustments only to bring its
> frequency back into line (but currently gets more than this
> in Linux). CLOCK_REALTIME should and does get adjustments
> for frequency and then gets further, temporary speedups
> or slowdown to bring its absolute value back into line.
That would make a rather useless CLOCK_MONOTONIC. The basic problem is
that it would be very hard to specify the time without exactly knowing
it's frequency, the larger the time difference the larger the time skew
would be compared to CLOCK_REALTIME and without an atomic clock in your
computer you have no way of knowing which one is "real".
So in practice it's easier to advance CLOCK_MONOTONIC/CLOCK_REALTIME
equally and only apply time jumps to CLOCK_REALTIME.
bye, Roman
On Sep 1, 2005, at 11:18:52, Roman Zippel wrote:
> On Thu, 1 Sep 2005, Joe Korty wrote:
>> On Thu, Sep 01, 2005 at 11:19:51AM +0200, Roman Zippel wrote:
>>> You still didn't explain what's the point in choosing
>>> different clock sources for a _timeout_.
>>
>> Well, if CLOCK_REALTIME is set forward by a minute,
>> timers & timeout specified against that clock will expire
>> a minute earlier than expected.
>
> That just rather suggests that the pthread API is broken as usual.
> (No other possible user was mentioned so far.)
How about a hypothetical time-based event daemon. I want to run
some jobs every 10 minutes that the system is running (not off or
suspended), I want to run other jobs every hour in real time, and
if one such timer expires while suspended, I want to run it
immediately to catch up. The first suggests CLOCK_MONOTONIC, and
the second works better with CLOCK_REALTIME.
> So in practice it's easier to advance CLOCK_MONOTONIC/CLOCK_REALTIME
> equally and only apply time jumps to CLOCK_REALTIME.
I thought that's what he said, but maybe I'm just confused :-D.
Cheers,
Kyle Moffett
--
Premature optimization is the root of all evil in programming
-- C.A.R. Hoare