Clock Pulse?

Discussion in 'C Programming' started by luserXtrog, Sep 18, 2009.

  1. luserXtrog

    luserXtrog Guest

    Does anyone have any advice on how best to call a function
    once a minute to change a clock face?

    My thought so far is:
    { time_t tt;
    struct tm *ptm;
    time(&tt);
    ptm = localtime(&tt);
    sleep /* sleep is posix, isn't it? */
    (ptm->tm_sec);
    while(1) {
    my_func();
    sleep(60);
    }
    }

    Without posix, would I have to do a busy loop?

    --
    lease rtr
     
    luserXtrog, Sep 18, 2009
    #1
    1. Advertising

  2. "luserXtrog" <> wrote in message
    news:...
    > Does anyone have any advice on how best to call a function
    > once a minute to change a clock face?
    >
    > My thought so far is:
    > { time_t tt;
    > struct tm *ptm;
    > time(&tt);
    > ptm = localtime(&tt);
    > sleep /* sleep is posix, isn't it? */
    > (ptm->tm_sec);
    > while(1) {
    > my_func();
    > sleep(60);
    > }
    > }


    You're not taking the return value of `sleep()' into account. IIRC, you need
    something along the lines of:
    ________________________________________________________________
    void
    sleep_foo(unsigned int seconds)
    {
    while ((seconds = sleep(seconds)));
    }


    void
    clock_update(void)
    {
    for (;;)
    {
    sleep_foo(60);

    my_func();
    }
    }
    ________________________________________________________________




    > Without posix, would I have to do a busy loop?


    Not if you used some other OS specific primitive. Otherwise, yes.
     
    Chris M. Thomasson, Sep 18, 2009
    #2
    1. Advertising

  3. On Sep 18, 11:33 am, luserXtrog <> wrote:
    > Does anyone have any advice on how best to call a function
    > once a minute to change a clock face?
    > ... [snip] ...
    >         sleep(60);


    It may seem like a nit, but you should handle the case where
    other applications delay your scheduling. In other words,
    if an extra second has elapsed, call sleep(59) for next time.

    The Sun/BSD iostat program had this (and other) bug(s),
    meaning that its output was very misleading in the most
    interesting (heavy load) cases.

    James
     
    James Dow Allen, Sep 18, 2009
    #3
  4. "James Dow Allen" <> wrote in message
    news:...
    On Sep 18, 11:33 am, luserXtrog <> wrote:
    > > Does anyone have any advice on how best to call a function
    > > once a minute to change a clock face?
    > > ... [snip] ...
    > > sleep(60);


    > It may seem like a nit, but you should handle the case where
    > other applications delay your scheduling. In other words,
    > if an extra second has elapsed, call sleep(59) for next time.


    > The Sun/BSD iostat program had this (and other) bug(s),
    > meaning that its output was very misleading in the most
    > interesting (heavy load) cases.


    Oh boy! I have observed, and had to correct, many codes with a __very__
    similar error... Think of something along the lines of:
    _____________________________________________
    void
    foo_wait(sem_t* s)
    {
    sem_wait(s);
    }
    _____________________________________________




    Wow! What a massive and horrific bug!!!!!




    Huston, we have a problem!


    ;^o
     
    Chris M. Thomasson, Sep 18, 2009
    #4
  5. luserXtrog

    luserXtrog Guest

    On Sep 18, 5:32 am, "Chris M. Thomasson" <> wrote:
    > "James Dow Allen" <> wrote in messagenews:...
    > On Sep 18, 11:33 am, luserXtrog <> wrote:
    >
    > > > Does anyone have any advice on how best to call a function
    > > > once a minute to change a clock face?
    > > >  ... [snip] ...
    > > > sleep(60);

    > > It may seem like a nit, but you should handle the case where
    > > other applications delay your scheduling.  In other words,
    > > if an extra second has elapsed, call sleep(59) for next time.
    > > The Sun/BSD iostat program had this (and other) bug(s),
    > > meaning that its output was very misleading in the most
    > > interesting (heavy load) cases.

    >
    > Oh boy! I have observed, and had to correct, many codes with a __very__
    > similar error... Think of something along the lines of:
    > _____________________________________________
    > void
    > foo_wait(sem_t* s)
    > {
    >     sem_wait(s);}
    >
    > _____________________________________________
    >
    > Wow! What a massive and horrific bug!!!!!
    >
    > Huston, we have a problem!
    >
    > ;^o


    I don't understand.
    How would one wait for a semaphore without waiting for
    a semaphore?
    Are you making some comment about making assumptions
    about the 'context'[1] during execution?

    At the risk of spoiling the joke, could you elaborate?

    [1] in the layman sense of "everything else that's going on".
    --
    this is my name down here somewhere
    maybe
     
    luserXtrog, Sep 19, 2009
    #5
  6. "luserXtrog" <> wrote in message
    news:...
    On Sep 18, 5:32 am, "Chris M. Thomasson" <> wrote:
    [...]
    > Oh boy! I have observed, and had to correct, many codes with a __very__
    > similar error... Think of something along the lines of:
    > _____________________________________________
    > void
    > foo_wait(sem_t* s)
    > {
    > sem_wait(s);}
    >
    > _____________________________________________
    >
    > Wow! What a massive and horrific bug!!!!!
    >
    > Huston, we have a problem!
    >
    > ;^o


    > I don't understand.
    > How would one wait for a semaphore without waiting for
    > a semaphore?
    > Are you making some comment about making assumptions
    > about the 'context'[1] during execution?


    > At the risk of spoiling the joke, could you elaborate?


    > [1] in the layman sense of "everything else that's going on".


    Read here first:


    http://www.opengroup.org/onlinepubs/7990989775/xsh/sem_wait.html


    Then try and think about what would happen if `sem_wait()' returns `EINTR'
    and the program responds to this event as if it were a legitimate decrement
    on the semaphore value...
     
    Chris M. Thomasson, Sep 19, 2009
    #6
  7. luserXtrog

    luserXtrog Guest

    On Sep 19, 1:25 am, "Chris M. Thomasson" <> wrote:
    > "luserXtrog" <> wrote in message
    >
    > news:...
    > On Sep 18, 5:32 am, "Chris M. Thomasson" <> wrote:
    > [...]
    >
    >
    >
    > > Oh boy! I have observed, and had to correct, many codes with a __very__
    > > similar error... Think of something along the lines of:
    > > _____________________________________________
    > > void
    > > foo_wait(sem_t* s)
    > > {
    > > sem_wait(s);}

    >
    > > _____________________________________________

    >
    > > Wow! What a massive and horrific bug!!!!!

    >
    > > Huston, we have a problem!

    >
    > > ;^o
    > > I don't understand.
    > > How would one wait for a semaphore without waiting for
    > > a semaphore?
    > > Are you making some comment about making assumptions
    > > about the 'context'[1] during execution?
    > > At the risk of spoiling the joke, could you elaborate?
    > > [1] in the layman sense of "everything else that's going on".

    >
    > Read here first:
    >
    > http://www.opengroup.org/onlinepubs/7990989775/xsh/sem_wait.html
    >
    > Then try and think about what would happen if `sem_wait()' returns `EINTR'
    > and the program responds to this event as if it were a legitimate decrement
    > on the semaphore value...


    so it should be more like:

    void foo_wait (sem_t *s) {
    int ret;
    do {
    ret = sem_wait(s);
    } while (ret == -1 && errno == EINTR);
    }

    ?

    --
    lxt
     
    luserXtrog, Sep 19, 2009
    #7
  8. "luserXtrog" <> wrote in message
    news:...
    On Sep 19, 1:25 am, "Chris M. Thomasson" <> wrote:
    > > "luserXtrog" <> wrote in message
    > >
    > > news:...
    > > On Sep 18, 5:32 am, "Chris M. Thomasson" <> wrote:
    > > [...]
    > >
    > >
    > >
    > > > Oh boy! I have observed, and had to correct, many codes with a
    > > > __very__
    > > > similar error... Think of something along the lines of:
    > > > _____________________________________________
    > > > void
    > > > foo_wait(sem_t* s)
    > > > {
    > > > sem_wait(s);}

    > >
    > > > _____________________________________________

    > >
    > > > Wow! What a massive and horrific bug!!!!!

    > >
    > > > Huston, we have a problem!

    > >
    > > > ;^o
    > > > I don't understand.
    > > > How would one wait for a semaphore without waiting for
    > > > a semaphore?
    > > > Are you making some comment about making assumptions
    > > > about the 'context'[1] during execution?
    > > > At the risk of spoiling the joke, could you elaborate?
    > > > [1] in the layman sense of "everything else that's going on".

    > >
    > > Read here first:
    > >
    > > http://www.opengroup.org/onlinepubs/7990989775/xsh/sem_wait.html
    > >
    > > Then try and think about what would happen if `sem_wait()' returns
    > > `EINTR'
    > > and the program responds to this event as if it were a legitimate
    > > decrement
    > > on the semaphore value...

    > ______________________________________________________
    > so it should be more like:


    > void foo_wait (sem_t *s) {
    > int ret;
    > do {
    > ret = sem_wait(s);
    > } while (ret == -1 && errno == EINTR);
    > }
    > ______________________________________________________


    > ?



    That can still let some error's go by. Since the procedure `foo_wait()' does
    not return anything, I would do it like:
    ______________________________________________________
    void
    foo_wait(sem_t* s)
    {
    int status;

    while ((status = sem_wait(s)))
    {
    if (errno != EINTR)
    {
    assert(errno == EINTR);
    abort();
    }
    }
    }
    ______________________________________________________




    That should get the point across... ;^)




    Or, perhaps we should let the caller handle the error and turn `foo_wait()'
    into a function:
    ______________________________________________________
    int
    foo_wait(sem_t* s)
    {
    int status;

    while ((status = sem_wait(s)))
    {
    if (errno != EINTR)
    {
    return errno;
    }
    }

    return 0;
    }
    ______________________________________________________




    Now, if `foo_wait()' returns zero, that means the semaphore was actually
    decremented.


    :^)
     
    Chris M. Thomasson, Sep 20, 2009
    #8
  9. luserXtrog

    luserXtrog Guest

    On Sep 19, 9:04 pm, "Chris M. Thomasson" <> wrote:
    <snip improved use of sem_wait>

    >
    > That should get the point across...   ;^)


    Yes. Thank you.
    The similarity to the bug of a simple call to sleep() is
    also clear.

    --
    increasingly aware that this discussion belonged in c.u.p. all along
     
    luserXtrog, Sep 20, 2009
    #9
  10. luserXtrog

    Nobody Guest

    On Thu, 17 Sep 2009 21:33:33 -0700, luserXtrog wrote:

    > Does anyone have any advice on how best to call a function
    > once a minute to change a clock face?
    >
    > My thought so far is:
    > { time_t tt;
    > struct tm *ptm;
    > time(&tt);
    > ptm = localtime(&tt);
    > sleep /* sleep is posix, isn't it? */
    > (ptm->tm_sec);
    > while(1) {
    > my_func();
    > sleep(60);
    > }
    > }


    Don't rely upon sleep() sleeping for exactly the specified time. Instead,
    call sleep() repeatedly until you reach the desired point in time, e.g.:

    for (;;) {
    struct tm next_tm;
    time_t now, next;
    int diff;

    time(&now);
    next_tm = *localtime(&now);
    next_tm.tm_sec = 0;
    /* this may reach 60, but mktime() will normalise it */
    next_tm.tm_min++;
    next = mktime(&next_tm);

    while (diff = (int) floor(difftime(&next, &now)), diff > 0) {
    sleep(diff);
    time(&now);
    }

    /* we are now (approximately) at the minute mark */
    }

    > Without posix, would I have to do a busy loop?


    If all you have available is the ANSI C standard library, then you would
    need a busy loop.

    Note that if you are assuming POSIX, the above code can be simplified
    slightly based upon the fact that POSIX specifies time_t as an integer
    representing seconds since the epoch, so you can manipulate time_t values
    directly without neededing to use mktime() or difftime().
     
    Nobody, Sep 20, 2009
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Valentin Tihomirov

    Are clock and divided clock synchronous?

    Valentin Tihomirov, Oct 23, 2003, in forum: VHDL
    Replies:
    11
    Views:
    3,360
    louis lin
    Oct 28, 2003
  2. Replies:
    4
    Views:
    752
    Peter Alfke
    Apr 27, 2006
  3. Replies:
    5
    Views:
    2,234
    Ricardo
    Jun 23, 2006
  4. himassk
    Replies:
    1
    Views:
    1,254
    Paul Uiterlinden
    May 16, 2007
  5. JSreeniv

    change a clock to pulse in vhdl

    JSreeniv, Jan 31, 2010, in forum: VHDL
    Replies:
    1
    Views:
    2,060
    Mike Treseler
    Jan 31, 2010
Loading...

Share This Page