Numa and ReentrantLock

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Numa and ReentrantLock

MokshaVMohit

Hi Doug,

 

I have a requirement where-in I spin by calling “trylock()” a configured number of times before i go in for a blocking version.

Something like adaptive spinning on intrinsic locks.

 

My only concern is this spinning is on a single variable which would be on remote memory for all but one thread on NUMA machines.

 

Regards

Mohit


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Numa and ReentrantLock

Doug Lea
> Hi Doug,
>
>
>
> I have a requirement where-in I spin by calling "trylock()" a configured
> number of times before i go in for a blocking version.
>
> Something like adaptive spinning on intrinsic locks.

Yes, this is an intended common use for tryLock -- we in the
library don't know if/how you'd like to do adaptive spins,
but we try to make it easy to do so.

>
> My only concern is this spinning is on a single variable which would be on
> remote memory for all but one thread on NUMA machines.

This is unlikely to be a major concern, but you might heuristically
improve good-citizenship by occasionally invoking Thread.yield()
if you spin a lot. For example, yield every 64 spins. This has no
guaranteed effects, but in practice helps.

-Doug






>
>
> Regards
>
> Mohit
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Numa and ReentrantLock

MokshaVMohit
In reply to this post by MokshaVMohit
Hi Doug,

In the ConcurrentHashMap the get method does not require "readValueUnderLock" because a racing remove does not make the value null.
The value never becomes null on the from the removing thread. this means it is possible for get to return a value for key even if the removing thread (on the same key) has progressed till the point of cloning the preceding parts of the list.
This is fine so long as it is the desired effect.

But this means "readValueUnderLock" is not required for NEW memory model.

However for the OLD memory model a put may see the value null due to reordering(Rare but possible).

Is my understanding correct.

Thanks in advance
Mohit




_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Numa and ReentrantLock

Doug Lea
On 02/26/11 10:39, Mohit Kumar wrote:
> Hi Doug,
>
> In the ConcurrentHashMap the get method does not require "readValueUnderLock"
> because a racing remove does not make the value null.
>
> Is my understanding correct.
>

Not quite. You are right that it should never be called.
However, the JLS/JMM can be read as not absolutely
forbidding it from being called because of weaknesses
in required ordering relationships among finals
vs volatiles set in constructors (key is final, value is
volatile), wrt the reads by threads using the
entry objects. (In JMM-ese, ordering constraints for
finals fall outside of the synchronizes-with relation.)
That's the issue the doc comment (pasted below) refers to.
No one has ever thought of any practical loophole that a
processor/compiler might find to produce a null value read,
and it may be provable that none exist (and perhaps someday
a JLS/JMM revision will fill in gaps to clarify this),
but Bill Pugh once suggested we put this in anyway just
for the sake of being conservatively pedantically correct.
In retrospect, I'm not so sure this was a good idea, since
it leads people to come up with exotic theories.

...

      * Because the value field is volatile, not final, it is legal wrt
      * the Java Memory Model for an unsynchronized reader to see null
      * instead of initial value when read via a data race.  Although a
      * reordering leading to this is not likely to ever actually
      * occur, the Segment.readValueUnderLock method is used as a
      * backup in case a null (pre-initialized) value is ever seen in
      * an unsynchronized access method.
      */
     static final class HashEntry<K,V> {
         final K key;
         final int hash;
         volatile V value;
         final HashEntry<K,V> next;
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Numa and ReentrantLock

Kasper Nielsen-3
On 26-02-2011 17:16, Doug Lea wrote:
> On 02/26/11 10:39, Mohit Kumar wrote:
> In retrospect, I'm not so sure this was a good idea, since
> it leads people to come up with exotic theories.

Originally, my biggest trouble with understanding the code was why the
value iterator of CHM didn't make use of readValueUnderLock().
Now I just assume it is because nobody has been (or will be) bitten by
that particular reordering.

Cheers
   Kasper
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest