martinrb at google.com
Wed Jun 6 16:41:37 EDT 2018
Conceptually, ThreadLocal is very Map-like and one can examine methods on
Map to see whether they belong in ThreadLocal.
I recall being disappointed that remove() (added in 1.5) felt insufficient.
Something like isPresent could probably be used in ReentrantReadWriteLock.
You might want to try out any API change with ReentrantReadWriteLock.
Maybe we want the Map.compute* family of methods (except that the key is
On Wed, Jun 6, 2018 at 12:07 PM, Peter Levart via Concurrency-interest <
concurrency-interest at cs.oswego.edu> wrote:
> On 06/06/18 20:27, David Lloyd wrote:
> On Wed, Jun 6, 2018 at 1:17 PM, Peter Levart <peter.levart at gmail.com> <peter.levart at gmail.com> wrote:
> Or there could simply be the following method in ThreadLocal:
> * @return true if current thread has a value present for this thread-local
> variable; false if not.
> public boolean isPresent()
> Would that be preferable?
> That would work assuming no ThreadLocal subclasses have such a method.
> Adding an instance method to a class that can be subclassed is always
> a risk in this way.
> I think the risk is not so big because ThreadLocal instances are typically
> not publicly exposed. They are usually encapsulated and code accessing them
> "knows" the semantics of the isPresent() method if such method exists in a
> subclass. There is a danger though that such method on an existing subclass
> is not public and not private which would break binary link-ability if such
> public method was added to ThreadLocal...
> The risk can be avoided entirely with a static method taking a ThreadLocal
> instance. But static method is not so nice-looking when called... :-(
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest