tangruize

The current condition for checking if a read is lockable is `lock & (WRITER | MAX_READER | BEING_UPGRADED) == 0`, which does not fully utilize the 61 bits for the...

The `RwMutex` shares the same logic as `RwLock`. Currently, I haven't made any changes to the `RwMutex`. Contention with `read()` and `downgrade()` won't occur in RwMutex because it uses waiting...

Here is the performance test result (`irq_disabled` took less time, which differs from the results in #1310. I don't know why): [test code](https://github.com/tangruize/asterinas/tree/18da665c5b6facadd1cef829abcb336bfea3b59b), `make run` ### After fix `RwLock::read` time...

To make it more efficient, we can "inline" the `fetch_update()` method, which eliminate two closures. Below are the performance test results (https://github.com/tangruize/asterinas/commit/faf11bbaa7e4503278bfad510fca785f0d2826b2#): After fix: `RwLock::read` time consuming: `[136ns, 135ns, 132ns]`...

> Do you think that you can make RwLock correct but also as efficient as it is used to be? @tatetian It doesn't seem possible to be more efficient using...

Yes, I also think this is a trade-off between performance and absolute correctness. For now, we can keep the current implementation because Asterinas doesn't use the `downgrade()` method. However, other...

@tatetian Currently the `downgrade()` method is not used. I removed `RwLock.downgrade()` due to potential contention with `RwLock.read()`. Please review.

@tatetian Please review. Seems that some CI failures are not caused by this PR.

Thanks for the help @junyang-zh , here is the test result: - Hardware: Intel(R) Xeon(R) CPU E5-2673 v4 @ 2.30GHz - Software: Docker v0.8.1 + [this branch](https://github.com/tangruize/asterinas/tree/98dafd6fefa9bb916954b59ad5045dd43503c8e8) ```sh $ make...

~~Another potential consequence is that `try_read()` momentarily increasing the reader count could, in theory, overflow the maximum number of readers -- though with a practical limit of 2^{60}-1~~