Bug 180394 - CountingLock could avoid the isHeldBit check in tryOptimizedRead
Summary: CountingLock could avoid the isHeldBit check in tryOptimizedRead
Status: REOPENED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Template Framework (show other bugs)
Version: WebKit Nightly Build
Hardware: All All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-12-04 21:41 PST by Filip Pizlo
Modified: 2017-12-10 17:43 PST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Filip Pizlo 2017-12-04 21:41:38 PST
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.
Comment 1 Filip Pizlo 2017-12-10 15:43:11 PST

*** This bug has been marked as a duplicate of bug 180638 ***
Comment 2 Filip Pizlo 2017-12-10 17:43:13 PST
I shouldn't have duped this.