As the comment in CountingLock.h says: // FIXME: We could eliminate this check, if we think it's OK to proceed with the optimistic read // path even after knowing that it must fail. That's probably good for perf since we expect // failure to be super rare. We would get rid of this check and instead of calling getCount below, // we would return currentValue ^ mask. If the lock state was empty to begin with, the result // would be a properly blessed count (both low bits set). If the lock state was anything else, we // would get an improperly blessed count that would not possibly succeed in validate. We could // actually do something like "return (currentValue | hasParkedBit) ^ isHeldBit", which would mean // that we allow parked-but-not-held-locks through.
*** This bug has been marked as a duplicate of bug 180638 ***
I shouldn't have duped this.