[GitHub] [curator] kezhuw commented on pull request #445: CURATOR-621: Fix write acquire after downgrade InterProcessReadWriteLock

["kezhuw (via GitHub)" <gi...@apache.org>]

kezhuw commented on PR #445:
URL: https://github.com/apache/curator/pull/445#issuecomment-1471658870

   @tisonkun Thank you for reviewing. Given the test case `testContendingDowngrading` as example.
   
   1. Without this patch, `lock2` will succeed to acquire write after `lock1` downgrades its write to read since `lock2`'s write sequence is smaller than `lock1`'s read sequence.
   
   ```mermaid
   sequenceDiagram
   
   lock1 ->> Server: write acquire
   Server ->> lock1: __WRITE__0000000000
   Note right of lock1: write locked
   lock2 -->> Server: write acquire
   Server -->> lock2: __WRITE__0000000001
   Note left of lock2: wait for __WRITE__0000000000
   lock1 ->> Server: read acquire
   Server ->> lock1: __READ__0000000002
   activate lock1
   Note right of lock1: read locked since:<br/> lock1 owns write lock
   Note over lock1, lock2: lock1 holds write(0000000000) and read(0000000002), lock2 queues write(0000000001)
   lock1 ->> Server: write release
   par
   Server ->> lock1: delete __WRITE__0000000000
   Server -->> lock2: delete __WRITE__0000000000
   end
   activate lock2
   Note left of lock2: write locked since:<br/>0000000001(lock2's write) < 0000000002(lock1's read)
   Note over lock1,lock2:BUG: lock1 holds read(0000000002), lock2 holds write(0000000001)
   deactivate lock2
   deactivate lock1
   ```
   2. With this patch applied, `lock1` will get same sorting sequence as its write lock in downgrading so there is no possibility that contending locks could get smaller sorting sequence.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@curator.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org