Using clock() in threading on Windows

Discussion in 'Python' started by Maxim Khitrov, Feb 21, 2009.

  1. Greetings,

    The threading module uses time.time in _Condition and _Thread classes
    to implement timeouts. On Windows, time() typically has a resolution
    of 15.625ms. In addition, if the system clock is changed (though ntp,
    for example) it would reflect that change, causing the timeout to last
    longer or shorter depending on which way the update went.

    Would it not be better to use time.clock() instead? The resolution is
    much better, and the value is not linked to system clock. Right now, I
    replace the threading._time reference with clock in some of my
    programs and everything works perfectly. Condition and Event timeouts
    are precise down to the millisecond (resolution of the sleep
    function), and I see no side-effects.

    Is it possible to make that change part of the module itself (keeping
    time() for linux systems), or can someone think of a reason why using
    clock is a bad idea? I know that it's using QueryPerformanceCounter
    for implementation, which has some known issues, but I still think
    that the advantages outweigh potential faults.

    - Max
    Maxim Khitrov, Feb 21, 2009
    #1
    1. Advertising

  2. > Would it not be better to use time.clock() instead?

    If you really want to reconsider this implementation, I think it
    would be best to use relative timeouts all the way down to the
    system. In the specific case of Windows, WaitForSingleObject
    expects a relative number of milliseconds (i.e. a wait duration).
    As this is also what the Python script passes (in seconds),
    it is best to leave issues of timer resolution to the operating
    system (which we have to trust anyway).

    As a consequence, the half-busy loops could go away, at least
    on systems where lock timeouts can be given to the system.

    Regards,
    Martin
    Martin v. Löwis, Feb 21, 2009
    #2
    1. Advertising

  3. Maxim Khitrov

    David Bolen Guest

    "Martin v. Löwis" <> writes:

    > As a consequence, the half-busy loops could go away, at least
    > on systems where lock timeouts can be given to the system.


    I know that in some cases in the past I've had to bypass a Queue's use
    of threading objects for waiting for a queue to unblock because of the
    increased overhead (and latency as the timer increases) of the busy
    loop. On windows, replacing it with an implementation using
    WaitForObject calls with the same timeouts I would have used with the
    Queue performed much better, not unexpectedly, but was non-portable.

    The current interface to the lowest level locks in Python are
    certainly generic enough to cross lots of platforms, but it would
    definitely be useful if they could implement timeouts without busy
    loops on those platforms where they were supported.

    -- David
    David Bolen, Feb 22, 2009
    #3
    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,239
    louis lin
    Oct 28, 2003
  2. Replies:
    4
    Views:
    699
    Peter Alfke
    Apr 27, 2006
  3. Replies:
    5
    Views:
    2,131
    Ricardo
    Jun 23, 2006
  4. himassk
    Replies:
    1
    Views:
    1,214
    Paul Uiterlinden
    May 16, 2007
  5. pankaj.goel
    Replies:
    6
    Views:
    919
    pankaj.goel
    Nov 25, 2008
Loading...

Share This Page