arturobernalg commented on PR #307:
URL: https://github.com/apache/jspwiki/pull/307#issuecomment-1745343221
> Hi,
>
> interesting PR! :-) My only comment is that I'd extract the lock behaviour
on a utility class something similar to (pseudocode, surely doesn't even
compile):
>
> ```java
> public class Synchronizer {
>
> public static < T > T synchronize( final ReentrantLock lock, final
Supplier< T > supplier ) {
> lock.lock();
> try {
> return supplier.get();
> } finally {
> lock.unlock();
> }
> }
>
> }
> ```
>
> so code inside synchronized blocks can be passed as a lambda (also this
method could be overloaded so it could also receive some Runnable, Function,
etc.)
>
> WDYT?
>
> cheers, juan pablo
HI @juanpablo-santos
I agree that encapsulating the lock behavior in a utility class like
Synchronizer would offer several advantages, particularly in terms of code
Readability and Reusability.
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.
Best regards,
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
