[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