arturobernalg commented on PR #307:
URL: https://github.com/apache/jspwiki/pull/307#issuecomment-1754548191

   > The utility/class method focus should be more about synchronizing than 
locking (hence the names).
   
   
   
   > > Hi @arturobernalg !
   > > > However, this approach has limitations when it comes to working with 
condition variables and allowing for custom scenarios. Specifically, using a 
utility class for locking would make it challenging to implement more complex 
control flows that involve waiting for certain conditions to be met or 
signaling other threads to proceed.
   > > > In essence, while the utility class would make the code cleaner for 
basic locking and unlocking, it might not be flexible enough to handle advanced 
locking scenarios that require the use of conditions.
   > > 
   > > 
   > > I agree that more complex scenarios would **not** fit inside this 
utility class. However, the scope of the PR is to switch away from 
`synchronized` blocks, and for all them we have the same idiom all over the 
place:
   > > ```
   > > lock.lock();
   > > try {
   > >     doSomething();
   > > } finally {
   > >     lock.unlock();
   > > }
   > > ```
   > > 
   > > 
   > >     
   > >       
   > >     
   > > 
   > >       
   > >     
   > > 
   > >     
   > >   
   > > So abstracting it into a common method makes sense to me. If later on we 
want to refactor, or we want to capture more complex scenarios, we can always 
move away from the utility `synchronize` method. The utility/class method focus 
should be more about synchronizing than locking (hence the names).
   > > WDYT?
   > 
   > HI @juanpablo-santos It makes sense to start with this abstraction for the 
sake of code cleanliness and readability.
   > 
   > I'll go ahead and make the changes to incorporate the new method It might 
take me a couple of days to complete the update, but I'll keep you posted on 
the progress.
   > 
   > TY
   
   HI @juanpablo-santos 
   
   Implemented the custom Synchronizer class to manage ReentrantLock 
synchronization as planned. 
   The changes turned out to be more extensive than initially anticipated. 
   Looking forward to your feedback to determine if this approach works well 
for our use case.
   


-- 
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: dev-unsubscr...@jspwiki.apache.org

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

Reply via email to