[crac] RFR: RCU Lock - RW lock with very lightweight read- and heavyweight write-locking [v5]
Anton Kozlov
akozlov at openjdk.org
Thu Apr 13 13:26:09 UTC 2023
On Wed, 12 Apr 2023 15:02:05 GMT, Radim Vansa <duke at openjdk.org> wrote:
>> This implementation is suitable for uses where the write-locking happens very rarely (if at all), as in the case of CRaC checkpoint, and we don't want to slow down regular access to the protected resource.
>
> Radim Vansa has updated the pull request incrementally with one additional commit since the last revision:
>
> Add synchronized context
src/java.base/share/classes/jdk/crac/RCULock.java line 32:
> 30: * <strong>acquire</strong> the read-lock <strong>inside</strong> the critical
> 31: * section (at the beginning) and <strong>release</strong> it <strong>outside</strong>,
> 32: * preferrably in the <code>finally</code> block.
This assimetry in the interface does not look nice. Likely because the implementation, we can release the lock only outside a method with the critical code. But this leaks too much implementation details to the interface.
src/java.base/share/classes/jdk/crac/RCULock.java line 141:
> 139: * @param readCriticalMethods List of signatures for methods invoked in the read-critical section.
> 140: */
> 141: public RCULock(String[] readCriticalMethods) {
It's a big question, why (from the interface point of view) the lock should know methods in which it can be used.
The second tier question, why the method names are String[] and not Method[] at least.
-------------
PR Review Comment: https://git.openjdk.org/crac/pull/58#discussion_r1165507583
PR Review Comment: https://git.openjdk.org/crac/pull/58#discussion_r1165512496
More information about the crac-dev
mailing list