Re: bizarre timing results

From: Gav (gav_at_cs.york.ac.uk)
Date: 04/01/05

  • Next message: phil-news-nospam_at_ipal.net: "Re: one partition/filesystem, many root trees" 
    Date: Fri, 01 Apr 2005 14:50:52 +0100

    > Are you using signals, or how precisely are you waiting?

    i'm not using signals (*)

    i'm not sure how to answer the second question. the code usually goes
    something like this:

    [lock mutex]
    while([not a state i want])
       [wait on state changed condition associated with mutex]
    [do some processing]
    if([we changed the state])
       [wake all those waiting on condition]
    [unlock mutex]
     
    i'm not completely sure, but i suspect that most times, the condition
    variable will be woken only when a valid state is reached.

    >> anyway, i've now put a sched_yield in each thread after they
    >> complete one iteration (i.e. before they begin waiting for
    >> the other to finish their iteration); it doesn't seem to
    >> make any difference empirically:
    >
    > The yield() needs to be inside the check-loop, or you
    > have to use signals.

    i was uncertain about doing this originally, since the mutex is only given
    up through waiting on the condition; i assumed that if i yield()ed outside
    the condition then it would just hold stuff up, since nothing more could
    happen until the mutex was unlocked.

    <googles and reads...>

    having done some reading it is apparent that condition variables are
    implemented by futexes which appear to be kernel level wait queues. i've
    yet to read up on them, but here's what i've read so far.

    [http://www.ussg.iu.edu/hypermail/linux/kernel/0311.1/0684.html]
    [http://www.ussg.iu.edu/hypermail/linux/kernel/0203.2/0122.html]

    > This is no surprise if you are spinning (busywaiting)
    > on a lock.

    using conditions doesn't busy wait though right?

    > AFAIK, Linux threads are still lightweight processes.
    > The scheduler will spread these around to available CPUs,
    > but you may pay a MESI communications tax.

    mesi?

    would that be something to do with attempting to access the same memory
    segment simultaneously? or am i way off?

    thanks for your continuing help; it's being more enlightening.

    gav

    (*) generally i would prefer to not rely upon signals; in my experience
    their semantics wrt to threading was rather changeable (esp with stuff like
    nptl). also i guess they're not very portable, and i don't want to rule out
    porting to other platforms (read windows) at this stage.

  • Next message: phil-news-nospam_at_ipal.net: "Re: one partition/filesystem, many root trees"

    Relevant Pages

    • Re: [newbie] conditions: signal sent before waiter available?
      ... With a condition variable is a mutex associated. ... In the book, some examples demonstrate condition variables, waiting for signals, sending signals and awakening. ... So the usuale pattern to wait for a predicate is to lock the mutex that synchronize the access to the predicate and than check if that predicate is true. ...
      (comp.programming.threads)
    • Re: [newbie] conditions: signal sent before waiter available?
      ... > With a condition variable is a mutex associated. ... > the one waiting needs to lock the mutex before calling the wait function, ... > signals, sending signals and awakening. ... You are fundamentally misunderstanding how condition variables *must* be ...
      (comp.programming.threads)
    • Re: pthread_cond_wait and testing condition explicitly
      ... void wait_for_0_value { ... The waiting thread has released the mutex while it is suspended (you ... When a thread finally signals cond_broadcast, ...
      (comp.unix.programmer)
    • Re: Threads, conditions, sockets, selects...
      ... One thread is blocked on the condition variable, waiting ... Another thread changes the predicate, ... mutex before signalling. ... This is impossible if B signals while holding the mutex. ...
      (comp.unix.programmer)
    • Re: conditions: signal sent before waiter available?
      ... > one waiting needs to lock the mutex before ... > signals, sending signals and awakening. ... In the alarm example, the waiting ... > thread (call it w-thread) is created ...
      (comp.programming.threads)