Enrich the Lock interface

[Albert Attard]

Hello.

Thank you very much Pavel for helping me find more information about this.

After some research (mainly by Pavel) we found a thread, with subject "*Default
Functions for Lock Interface*", from October 2013 that discussed this exact
thing.  I don't believe that this thread is available on the internet, but
I may be wrong.

In this thread, two approaches were discussed.

   1. Add support for the try-with-resources
   2. Add default methods to the Lock interface


The second approach makes use of lambda functions which incur performance
cost when data is modified within the lambda function, as described by
Brian Goetz in the same thread (on the 8th of October 2013).

---















*When you write a method likevoid withLock(Runnable)the Runnable is going
to have side-effects. So its going to be a capturing lambda -- one that
captures variables from its scope:withLock( () -> { counter++; } ); //
counter is capturedWith the current implementation of lambda, evaluating
(not invoking) a capturing lambda expression will cause an allocation.
Whereas the hand-unrolled version:lock.lock();try { counter++; } finally {
lock.unlock(); }does not. The sort of things people do with locks are
generally pretty performance-sensitive, so such an API was deemed, at the
current time, to be an "attractive nuisance."*---

Almost 10 years have passed since this was originally suggested.  Have
enough things changed since then, that would make this approach feasible?

With kind regards,
Albert Attard


On Mon, 21 Aug 2023 at 15:33, John Hendrikx <john.hendrikx at gmail.com> wrote:

> I couldn't find a discussion on openjdk, but for those interested (and
> to save others some searching) there is a JBS ticket:
>
> https://bugs.openjdk.org/browse/JDK-8025597
>
> --John
>
> On 21/08/2023 14:37, Pavel Rappo wrote:
> > This is suggested every once in a while. I appreciate that openjdk
> mailing lists are not easily searchable, but with a bit of skill, you could
> find a few previous discussions on the topic.
> >
> > This has also been discussed on concurrency-interest (at cs.oswego.edu <
> http://cs.oswego.edu/>), a dedicated mailing list for concurrency in
> Java. Sadly, that list has been defunct for quite some time now.
> >
> > -Pavel
> >
> >> On 21 Aug 2023, at 13:18, Albert Attard <albertattard at gmail.com> wrote:
> >>
> >> Hello.
> >>
> >> I hope all is well.
> >>
> >> Do you believe it is a bad idea to enrich the Lock interface with a set
> of default methods that safely release the lock once ready?
> >>
> >> Consider the following (dangerous) example.
> >>
> >> final Lock lock = new ReentrantLock ();
> >> lock.lock();
> >> /* Code that may throw an exception */
> >> lock.unlock();
> >>
> >> This example will never release the lock if an exception is thrown, as
> the programmer didn’t wrap this up in a try/finally.
> >>
> >> Adding a default method within the Lock interface, called
> withLock(Runnable) for example or any better name, would streamline this,
> as shown next.
> >>
> >> default void withLock(final Runnable runnable) {
> >>      requireNonNull(runnable, "Cannot run a null");
> >>      lock();
> >>      try {
> >>          runnable.run();
> >>      } finally {
> >>          unlock();
> >>      }
> >> }
> >>
> >> The caller can now simply change the above example into the following,
> without having to worry about this.
> >>
> >> final Lock lock = new ReentrantLock ();
> >> lock.withLock(() -> {
> >>    /* Code that may throw an exception */
> >> });
> >>
> >> We can have more variants of these default methods, as shown next.
> >>
> >> default <T> T getWithLock(final Supplier<T> supplier) {
> >>      requireNonNull(supplier, "The supplier cannot be null");
> >>      lock();
> >>      try {
> >>          return supplier.get();
> >>      } finally {
> >>          unlock();
> >>      }
> >> }
> >>
> >> Any thoughts?
> >>
> >> With kind regards,
> >> Albert Attard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230821/c6235a36/attachment.htm>