[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