Subj : Re: Linking without -lpthread doesn't fail?? To : comp.programming.threads From : David Butenhof Date : Mon Oct 10 2005 11:40 am David Schwartz wrote: > "David Butenhof" wrote in message > news:7gu1f.14123$zm1.5268@news.cpqcorp.net... > >> David Schwartz wrote: > >>> 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. > > If it indicates the successful creation of a mutex and condition > variable, then it should support their semantics. Otherwise, it's lying when > it said it succeeded. If the program is linked non-threaded, and there's no way for that to change dynamically, then the stubbed mutex or CV *was* created successfully, regardless of the fact that it can't actually DO anything. Beyond that you're arguing philosophy and I don't care to spend my time today pursuing that line of discussion. On Tru64 and VMS, the "stubs" were designed to allow dynamic activation of the thread library, so they really did something -- not just on init but on lock/unlock; you could lock a "stub" mutex, dynamically activate libpthread, create a thread, and an attempt to lock the "stub" mutex would block until the "previously single-threaded" holder unlocked. However, at any given wait call, either there's another thread already, or there never will be. If the thread library isn't active, there cannot be now or in the future, so the wait call can either fail or hang the program; there's no other possibility. POSIX doesn't recognize the possibility of a "non-threaded program with pthread support" -- either there are no threads (_POSIX_THREADS is undefined) or else every process is (potentially) threaded. That is, there can be "single-threaded" processes that happen to have not created a second thread, but not "non-threaded" processes incapable of creating threads. So any implementation that allows for "stubbed" functions in "non-threaded" processes, is nonstandard. It's a concession to history and expectations. >> 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. > > Right except ... > >> 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. > > Exactly. And your point is...? As I said, stubs are non-standard. They're a pragmatic concession to supporting historical expectations the vendor finds important... for whatever reason(s). If you disagree with a particular implementation's tradeoffs, take it up with them. Arguing here is pointless. -- 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 .