From fd8eb2372af758f5b5e91ac82f7ba02b903bae10 Mon Sep 17 00:00:00 2001 From: rpj Date: Wed, 10 Dec 2003 01:58:13 +0000 Subject: *** empty log message *** --- BUGS | 35 ++++++++++++++++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-) (limited to 'BUGS') diff --git a/BUGS b/BUGS index c7920b0..5f49609 100644 --- a/BUGS +++ b/BUGS @@ -102,4 +102,37 @@ Known bugs the pthreads library. - +3. sem_getvalue sometimes returns lower value than expected + + The following comments from the code explain the problem: + + /* + * There appears to be NO atomic means of determining the + * value of the semaphore. Using only ReleaseSemaphore() + * with either a zero or oversized count parameter has been + * suggested but this trick doesn't produce consistent results + * across Windows versions (the technique uses values that are + * knowingly illegal but hopes to extract the current value + * anyway - the zero parameter appears to work for Win9x but + * neither work reliably for WinNT). + * + * The intrusive method below will give false results + * at times but it at least errs on the side of + * caution. Competing threads might occasionally believe + * the semaphore has a count of one less than it actually + * would have and possibly block momentarily unecessarily, + * but they will never see a higher semaphore value than + * there should be. + * + * + * Multiple threads calling sem_getvalue() at the same time + * may not all return the same value (assuming no calls to + * other semaphore routines). They will always return the + * correct value or a lesser value. This problem could be fixed + * with a global or a per-semaphore critical section here. + * + * An equally approximate but IMO slightly riskier approach + * would be to keep a separate per-semaphore counter and + * decrement/increment it inside of sem_wait() and sem_post() + * etc using the Interlocked* functions. + */ -- cgit v1.2.3