JCIP seems to call this idea a monitor, but that’s also the general
implicit locking mechanism in Java.

On Tue, Jul 7, 2020 at 17:56 Gary Gregory <garydgreg...@gmail.com> wrote:

> Typo: LockingVisitors.
>
> On Tue, Jul 7, 2020 at 6:56 PM Gary Gregory <garydgreg...@gmail.com>
> wrote:
>
> > In the PR  https://github.com/apache/commons-lang/pull/559 I am going
> > with "LockingVistors".
> >
> > Gary
> >
> > On Tue, Jul 7, 2020 at 2:33 PM Rob Tompkins <chtom...@gmail.com> wrote:
> >
> >> I’m not all that familiar with that area of academia. Let me see what I
> >> can dig up
> >>
> >> -Rob
> >>
> >> > On Jul 7, 2020, at 2:19 PM, Matt Sicker <boa...@gmail.com> wrote:
> >> >
> >> > Are there any academic references for this? Or even something from
> >> > Java Concurrency in Practice? Those are good sources for names around
> >> > concurrency.
> >> >
> >> > On Tue, 7 Jul 2020 at 12:42, Rob Tompkins <chtom...@gmail.com> wrote:
> >> >>
> >> >> Why not make the name “ThreadedLambdaSynchronizer” or something like
> >> that….just something more descriptive here that get’s closer to what the
> >> intended functionality is.
> >> >>
> >> >> That said, I’m not particularly tied to the name
> >> “ThreadedLambdaSynchronizer” just spitballing here for something more
> >> descriptive than “Lock”
> >> >>
> >> >> -Rob
> >> >>
> >> >>> On Jun 29, 2020, at 12:58 PM, Matt Sicker <boa...@gmail.com> wrote:
> >> >>>
> >> >>> Now that starts to sound like Apache Groovy or Kotlin.
> >> >>>
> >> >>> On Mon, 29 Jun 2020 at 11:58, Xeno Amess <xenoam...@gmail.com>
> wrote:
> >> >>>>
> >> >>>> soemtimes I really wish to rewrite/add some functions in jdk
> >> directly...
> >> >>>> especially for reusing some package private static functions...
> >> >>>>
> >> >>>> Gary Gregory <garydgreg...@gmail.com> 于2020年6月30日周二 上午12:01写道:
> >> >>>>
> >> >>>>> I'm not sure talking to the JDK folks is helpful IMO. We are still
> >> >>>>> targeting Java 8. The customers I deal with are migrating from 8
> to
> >> 11, and
> >> >>>>> Java 11 is not everywhere our customers are. So talking about
> >> something
> >> >>>>> that might end up in Java... 25 seems to be not in our user's best
> >> or
> >> >>>>> immediate interest. It might be good for Java in the long oh so
> >> long term
> >> >>>>> of course.
> >> >>>>>
> >> >>>>> Gary
> >> >>>>>
> >> >>>>> On Mon, Jun 29, 2020 at 8:31 AM Rob Tompkins <chtom...@gmail.com>
> >> wrote:
> >> >>>>>
> >> >>>>>> At first look, I’m a little surprised we’re trying to take on
> this
> >> >>>>>> functionality. Has anyone reached out to the JDK guys to see if
> >> they’d be
> >> >>>>>> interested in having it in the JDK? That said, if we approach it
> >> from
> >> >>>>> that
> >> >>>>>> path, we would lose the functionality in older versions of java.
> So
> >> >>>>> maybe I
> >> >>>>>> just talked myself out of the idea of putting it in the JDK....
> >> >>>>>>
> >> >>>>>> Just wanted to stream of consciousness my initial gut vibe.
> >> >>>>>>
> >> >>>>>> Cheers,
> >> >>>>>> -Rob
> >> >>>>>>
> >> >>>>>>> On Jun 26, 2020, at 10:07 AM, Gary Gregory <
> >> garydgreg...@gmail.com>
> >> >>>>>> wrote:
> >> >>>>>>>
> >> >>>>>>> Hi All:
> >> >>>>>>>
> >> >>>>>>> I know email is a challenging medium for code reviews, so please
> >> >>>>> consider
> >> >>>>>>> these comments coming from my best intentions, constructive and
> >> caring
> >> >>>>>> ;-)
> >> >>>>>>> Also please excuse the meandering nature of this post.
> >> >>>>>>>
> >> >>>>>>> The new class org.apache.commons.lang3.concurrent.Locks.Lock
> needs
> >> >>>>> better
> >> >>>>>>> names IMO, not just the class name. There is already a JRE
> >> interface
> >> >>>>>> called
> >> >>>>>>> Lock so this class name is confusing (to me.)
> >> >>>>>>>
> >> >>>>>>> The Javadoc reads in part:
> >> >>>>>>>
> >> >>>>>>>   * This class implements a wrapper for a locked (hidden)
> object,
> >> and
> >> >>>>>>>   * provides the means to access it. The basic idea, is that the
> >> user
> >> >>>>>>>   * code forsakes all references to the locked object, using
> only
> >> the
> >> >>>>>>>   * wrapper object, and the accessor methods
> >> >>>>>>>
> >> >>>>>>> But this is not the case, the object itself is not locked in
> >> >>>>>>> the traditional sense with a monitor through a synchronized
> >> block, so
> >> >>>>> we
> >> >>>>>>> need to update the Javadoc as well.
> >> >>>>>>>
> >> >>>>>>> To me, this is more about executing blocks of code (through
> >> lambdas)
> >> >>>>>> which
> >> >>>>>>> then get 'safe' (via locking) access to an underlying object.
> This
> >> >>>>> tells
> >> >>>>>> me
> >> >>>>>>> the class is more about the functional interfaces than about a
> >> domain
> >> >>>>>>> "Object", hence the name "Lock" is not the best. It's really
> more
> >> of a
> >> >>>>>>> visitor where the visitation pattern is: Lock, Visit, Unlock.
> >> >>>>>>> Instead, maybe:
> >> >>>>>>> - StampledLockVisitor (more specific)
> >> >>>>>>> - LockingVisitor (more general)
> >> >>>>>>> - SafeObject (vague)
> >> >>>>>>> - ObjectLocker (vague)
> >> >>>>>>> - rejected: LockedObject since the object itself is not locked.
> >> >>>>>>> - ?
> >> >>>>>>>
> >> >>>>>>> What is also confusing IMO is that the instance variable for the
> >> object
> >> >>>>>> is
> >> >>>>>>> called "lockedObject" but the object is in fact NOT locked all
> the
> >> >>>>> time.
> >> >>>>>> So
> >> >>>>>>> that needs to be renamed IMO:
> >> >>>>>>> - object (the simplest)
> >> >>>>>>> - subject
> >> >>>>>>> - domain
> >> >>>>>>> - target
> >> >>>>>>> - ?
> >> >>>>>>>
> >> >>>>>>> In the same vein, the StampedLock is named "lock" which is also
> >> >>>>> confusing
> >> >>>>>>> since StampedLock does not implement Lock.
> >> >>>>>>>
> >> >>>>>>> Why can't the domain object be null, it's never used by the
> >> framework?
> >> >>>>>>> Why this:
> >> >>>>>>>              if (t == lockedObject) {
> >> >>>>>>>                  throw new IllegalStateException("The returned
> >> object
> >> >>>>>>> is, in fact, the hidden object.");
> >> >>>>>>>              }
> >> >>>>>>> ?
> >> >>>>>>> This seems like an application specific constraint that has
> >> nothing to
> >> >>>>> do
> >> >>>>>>> with the framework.
> >> >>>>>>>
> >> >>>>>>> Now that I've considered the above, the API Locks.lock(O) is
> >> really
> >> >>>>>>> misnamed, because it does not lock anything, it's a factory
> >> method.
> >> >>>>>>>
> >> >>>>>>> Stepping back even more, since there is only a static inner
> class
> >> in
> >> >>>>>> Locks,
> >> >>>>>>> and no-hint that alternative implementations for different kind
> of
> >> >>>>> locks
> >> >>>>>>> are possible, I would say we do not need Locks, all we need is
> >> what is
> >> >>>>>> now
> >> >>>>>>> called Lock.
> >> >>>>>>>
> >> >>>>>>> It's not clear why some methods are protected, I would make
> those
> >> >>>>>> private.
> >> >>>>>>> It's not like I can use or plugin a Lock,
> ReentrantReadWriteLock,
> >> a
> >> >>>>>>> ReentrantLock, or any ReadWriteLock instead of a StampedLock. I
> >> would
> >> >>>>>> then
> >> >>>>>>> make the current Lock class a standalone class which can then be
> >> used
> >> >>>>>> later
> >> >>>>>>> from a factory class (now Locks) where we can then fill in with
> >> >>>>> different
> >> >>>>>>> implementations.
> >> >>>>>>>
> >> >>>>>>> The Javadoc talks about a "hidden" object but it is not hidden
> >> since it
> >> >>>>>> is
> >> >>>>>>> passed to all visitors!
> >> >>>>>>>
> >> >>>>>>> This test assumption is wrong:
> >> >>>>>>>
> >> >>>>>>>       If our threads are running concurrently, then we expect to
> >> be
> >> >>>>>>> faster
> >> >>>>>>>       than running one after the other.
> >> >>>>>>>
> >> >>>>>>> The VM or Java spec makes no such guarantee and the tests have
> no
> >> >>>>> control
> >> >>>>>>> over VM scheduling. There are cases where this will fail when
> >> under
> >> >>>>> heavy
> >> >>>>>>> load for example where the cost of additional threads becomes
> >> >>>>>> overwhelming.
> >> >>>>>>>
> >> >>>>>>> Another item I am quite doubtful about is hiding checked
> >> exceptions by
> >> >>>>>>> rethrowning them as unchecked. I'd consider this an
> anti-pattern.
> >> If I
> >> >>>>> am
> >> >>>>>>> using one of our "Failing" interfaces it is because I am
> >> expecting it
> >> >>>>> to
> >> >>>>>>> fail. Perhaps this could be made smoother by refactoring to pass
> >> in a
> >> >>>>>>> lambda for an exception handler.
> >> >>>>>>>
> >> >>>>>>> I've crystallized my thoughts into code here as WIP (Javadoc
> needs
> >> >>>>> work):
> >> >>>>>>> https://github.com/apache/commons-lang/pull/559
> >> >>>>>>>
> >> >>>>>>> Not as important as the above:
> >> >>>>>>> The example in the Javadoc uses logging as its domain subject, a
> >> >>>>>> "logging"
> >> >>>>>>> API (PrintStream) which is not a good example IMO. Logging
> >> frameworks
> >> >>>>>>> today like Log4j handle multi-threaded applications normally
> >> without
> >> >>>>>> having
> >> >>>>>>> developers meddle in it. Yes, I understand it's a simple example
> >> but I
> >> >>>>> am
> >> >>>>>>> hoping we can come up with something more realistic or useful.
> >> >>>>>>>
> >> >>>>>>> Thank you,
> >> >>>>>>> Gary
> >> >>>>>>
> >> >>>>>>
> >> ---------------------------------------------------------------------
> >> >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
> >> >>>>>>
> >> >>>>>>
> >> >>>>>
> >> >>>
> >> >>>
> >> >>>
> >> >>> --
> >> >>> Matt Sicker <boa...@gmail.com>
> >> >>>
> >> >>>
> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> >>> For additional commands, e-mail: dev-h...@commons.apache.org
> >> >>>
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >> >>
> >> >
> >> >
> >> > --
> >> > Matt Sicker <boa...@gmail.com>
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> > For additional commands, e-mail: dev-h...@commons.apache.org
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
>
-- 
Matt Sicker <boa...@gmail.com>

Reply via email to