diff options
author | rpj <rpj> | 2004-11-03 07:54:20 +0000 |
---|---|---|
committer | rpj <rpj> | 2004-11-03 07:54:20 +0000 |
commit | 6fc46312bc9c0cddcd9d02248cd595050f55d4e3 (patch) | |
tree | ec4abdbd8b67cbbbaee292977a3a39d057d3a298 | |
parent | 1d5390bb01891f1d82c9ade54d28c9513f01982f (diff) |
-rw-r--r-- | BUGS | 35 |
1 files changed, 0 insertions, 35 deletions
@@ -101,38 +101,3 @@ Known bugs creation of production code is highly unreliable for the current version of
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.
- */
|