Subj : Re: Linking without -lpthread doesn't fail?? To : comp.programming.threads From : David Butenhof Date : Fri Oct 07 2005 01:56 pm David Schwartz wrote: > wrote in message > news:1128586872.311069.186080@o13g2000cwo.googlegroups.com... > >> I'm calling pthread_cond_timedwait not pthread_cond_wait . I'm waiting >> for ETIMEDOUT. We us this instead of the other delay calls because it >> a better job of relinguishing the CPU while sleeping. The others do not >> at all. At least not in programs running RT SCHED_FIFO. It is probably >> the only pthread* call we use outside of a so called threaded app. > > Frankly, I'm surprised it indicated the successful creation of a mutex > and condition variable. I agree, it should not allow you to create a mutex > and condition variable and then not time out. The non-thread pthread stubs SHOULD allow you to allocate and initialize both mutexes and condition variables. You should be able to lock and unlock mutexes -- there's no chance of lock contention because there's only one thread. Some might implement lock and unlock as empty stubs; others might do consistency checking. You shouldn't be able to WAIT on a condition variable, because there's no way the waiting thread could ever be awakened. But correct program logic makes that irrelevant because there's no way a predicate could fail to be satisfied (i.e., no reason to ever wait). Or at least, if there ever is a reason/need to wait the program is completely broken anyway and will just hang. Timed wait is a special case, though, because there is a common idiom of treating ETIMEDOUT as the predicate condition, and that can be satisfied without another thread. In MY non-threaded stubs, the function pthread_cond_timedwait() would simply "sleep" until the timeout. -- Dave Butenhof, David.Butenhof@hp.com HP Utility Pricing software, POSIX thread consultant Manageability Solutions Lab (MSL), Hewlett-Packard Company 110 Spit Brook Road, ZK2/3-Q18, Nashua, NH 03062 .