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
