Possible bug in CAGuard
Possible bug in CAGuard
- Subject: Possible bug in CAGuard
- From: Philippe Wicker <email@hidden>
- Date: Mon, 14 Jul 2003 14:50:56 +0200
Hi,
While walking through the code of CAGuard (CoreAudio/PublicUtility), I
found some coding that may be buggy in CAGuard::Wait and similar
methods. The code contains the line:
OSStatus theError = pthread_cond_wait(&mCondVar, &mMutex);
This line is not enclosed with something like:
while (! the_predicate_associated_with_the_cond) {
OSStatus theError = pthread_cond_wait ....
}
pthread_cond_wait can sometimes spuriously return 0 (no error) even if
the pthread_cond has not been signaled by a call to
pthread_cond_signal. To guard against those spurious wake up, the
predicate must be reevaluated upon return. Confirmation of this
behavior can be found in an answer to a posting I made on the Darwin
dev list (subject "Spurious wake up from pthread_cond_wait").
The CAGuard::Wait code does not use any predicate at all. Should I
consider this as a bug, or do you consider that it is the calling code
responsibility to detect a spurious wake up?
I searched the use of CAGuard::Wait() in the sample codes in the SDK.
Samples do not enclose the call to Wait() within a while (! predicate)
{ } loop. For instance, the RecordableFile::WriteNextBlock() method
contains the code:
if (! mThreadHasMoreWorkToDo) {
fileWriteLock.Wait ();
}
Shouldn't it be "while (! mThreadHasMoreWorkToDo) { .... }" ?
Regards,
Philippe Wicker
email@hidden
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.