Bug 180394
| Summary: | CountingLock could avoid the isHeldBit check in tryOptimizedRead | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Filip Pizlo <fpizlo> |
| Component: | Web Template Framework | Assignee: | Nobody <webkit-unassigned> |
| Status: | REOPENED | ||
| Severity: | Normal | ||
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | All | ||
| OS: | All | ||
Filip Pizlo
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Filip Pizlo
*** This bug has been marked as a duplicate of bug 180638 ***
Filip Pizlo
I shouldn't have duped this.