[concurrency-interest] Concurrency-interest Digest, Vol 99, Issue 41

Victor Grazi vgrazi at gmail.com
Wed Apr 17 12:59:24 EDT 2013


Thanks Nathan
As Heinz points out this is the correct RW Lock behavior as of Java 6 (it
could also be obtained in java 5 using a Fair Boolean in the Reentrant RW
lock constructor.
As far as the concurrent hash map, all of the animations work that way,
just press the button two or three times to experience the effect.

Regards, Victor

On Wednesday, April 17, 2013, wrote:

> Send Concurrency-interest mailing list submissions to
>         concurrency-interest at cs.oswego.edu <javascript:;>
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> or, via email, send a message with subject or body 'help' to
>         concurrency-interest-request at cs.oswego.edu <javascript:;>
>
> You can reach the person managing the list at
>         concurrency-interest-owner at cs.oswego.edu <javascript:;>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Concurrency-interest digest..."
>
>
> Today's Topics:
>
>    1. Re: New version of Java Concurrent Animated (Nathan Reynolds)
>    2. Re: ConcurrentHashMap-Very Strange behavior of ReentrantLock
>       under contention. (Nathan Reynolds)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 17 Apr 2013 09:15:02 -0700
> From: Nathan Reynolds <nathan.reynolds at oracle.com <javascript:;>>
> To: "Dr Heinz M. Kabutz" <heinz at javaspecialists.eu <javascript:;>>
> Cc: concurrency-interest at cs.oswego.edu <javascript:;>
> Subject: Re: [concurrency-interest] New version of Java Concurrent
>         Animated
> Message-ID: <516ECA86.3050303 at oracle.com <javascript:;>>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> Shouldn't the code sleep for 250+ seconds to give enough time for
> Thread.start()?  ;)
>
> Thanks for testing this.  This raises an interesting case. Interleave
> threads so that readLock().lock() and writeLock().lock() are alternately
> called.  If this behavior is followed, then the reader will have
> exclusive access to the critical region since it comes between two writers.
>
> Isn't this a throughput problem?  Shouldn't all of the readers be
> allowed to enter the critical region together and thus improve
> throughput through the lock?  This means changing the behavior so that
> writers get high priority and always enter the lock first otherwise they
> will starve.  When all writers are done, all of the readers will be able
> to enter the lock concurrently.  What's the problem with this scheme?
>
> Nathan Reynolds
> <http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> |
> Architect | 602.333.9091
> Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
> On 4/17/2013 12:06 AM, Dr Heinz M. Kabutz wrote:
> > Interesting thing about Victor's animations is that they hook directly
> > into what is happening inside the concurrency constructs.  Thus if you
> > run that particular example in Java 5, you will see how the readers
> > keep on getting in, even if a writer is waiting.  And in Java 6+ it
> > actually does work as Victor's animation shows, as can be also seen if
> > you run this code:
> >
> > import java.util.concurrent.locks.*;
> >
> > public class ReentrantReadWriteLockTest {
> >     public static void main(String[] args) throws InterruptedException {
> >         final ReadWriteLock rwlock = new ReentrantReadWriteLock();
> >
> >         // Thread #1 calls writeLock().lock() and enters the critical
> > region.
> >         waitForWriteLock(rwlock, "t1");
> >         Thread.sleep(100);
> >
> >         // Thread #2 calls readLock().lock() and blocks.
> >         waitForReadLock(rwlock, "t2");
> >         Thread.sleep(100);
> >
> >         // Thread #3 calls readLock().lock() and blocks.
> >         waitForReadLock(rwlock, "t3");
> >         Thread.sleep(100);
> >
> >         // Thread #4 calls readLock().lock() and blocks.
> >         waitForReadLock(rwlock, "t4");
> >         Thread.sleep(100);
> >
> >         // Thread #5 calls readLock().lock() and blocks.
> >         waitForReadLock(rwlock, "t5");
> >         Thread.sleep(100);
> >
> >         // Thread#6 calls writeLock ().lock() and blocks.
> >         waitForWriteLock(rwlock, "t6");
> >
> >         // Thread#1 releases the lock.
> >     }
> >
> >     private static void waitForReadLock(final ReadWriteLock rwlock,
> > String name) {
> >         new Thread(name) {
> >             public void run() {
> >                 System.out.println("Thread " + getName() + " waiting
> > for read lock");
> >                 rwlock.readLock().lock();
> >                 try {
> >                     System.out.println("Thread " + getName() + " is in
> > read section");
> >                     Thread.sleep(2000);
> >                 } catch (InterruptedException e) {
> >                     Thread.currentThread().interrupt();
> >                 } finally {
> >                     rwlock.readLock().unlock();
> >                 }
> >             }
> >         }.start();
> >     }
> >
> >     private static void waitForWriteLock(final ReadWriteLock rwlock,
> > String name) {
> >         new Thread(name) {
> >             public void run() {
> >                 System.out.println("Thread " + getName() + " waiting
> > for write lock");
> >                 rwlock.writeLock().lock();
> >                 try {
> >                     System.out.println("Thread " + getName() + " is in
> > write section");
> >                     Thread.sleep(2000);
> >                 } catch (InterruptedException e) {
> >                     Thread.currentThread().interrupt();
> >                 } finally {
> >                     rwlock.writeLock().unlock();
> >                 }
> >             }
> >         }.start();
> >     }
> > }
> >
> > The output is:
> >
> > Thread t1 waiting for write lock
> > Thread t1 is in write section
> > Thread t2 waiting for read lock
> > Thread t3 waiting for read lock
> > Thread t4 waiting for read lock
> > Thread t5 waiting for read lock
> > Thread t6 waiting for write lock
> > Thread t2 is in read section
> > Thread t3 is in read section
> > Thread t4 is in read section
> > Thread t5 is in read section
> > Thread t6 is in write section
> >
> > Regards
> >
> > Heinz
> > --
> > Dr Heinz M. Kabutz (PhD CompSci)
> > Author of "The Java(tm) Specialists' Newsletter"
> > Sun Java Champion
> > IEEE Certified Software Development Professional
> > http://www.javaspecialists.eu
> > Tel: +30 69 75 595 262
> > Skype: kabutz
> >
> >
> > Nathan Reynolds wrote:
> >> Nice animation!  I noticed a couple of problems.
> >>
> >> The ConcurrentHashMap demo fails to draw the threads if you keep
> >> hitting putIfAbsent.  The threads are drawn beyond the bottom.
> >>
> >> If I remember right ReentrantReadWriteLock gives priority to writer
> >> threads.  If that is the case then the ReadWriteLock demo is not
> >> quite right.
> >>
> >> Consider this scenario.
> >>
> >>  1. Thread #1 calls writeLock().lock() and enters the critical region.
> >>  2. Thread #2 calls readLock().lock() and blocks.
> >>  3. Thread #3 calls readLock().lock() and blocks.
> >>  4. Thread #4 calls readLock().lock() and blocks.
> >>  5. Thread #5 calls readLock().lock() and blocks.
> >>  6. Thread #6 calls writeLock().lock() and blocks.
> >>  7. Thread #1 releases the lock.
> >>  8. If writer threads are given priority, then Thread #6 should enter
> >>     the critical region.
> >>
> >> In the demo, threads #2 to #5 are given the lock in step 8.
> >>
> >> Nathan Reynolds
> >> <http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> |
> >> Architect | 602.333.9091
> >> Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
> >> On 4/16/2013 6:02 PM, Victor Grazi wrote:
> >>> Hi, just a quick note to let everyone know there is a new version of
> >>> Java Concurrent Animated on SourceForge.
> >>>
> >>> Some of the new features:
> >>> * A new animation showing good old synchronized/wait/notify. Kind of
> >>> surprising when you see it in action.
> >>> * Thread states are now color coded, and includes a novel state
> >>> diagram kind courtesy of Dr. Heinz Kabutz and his Concurrency
> >>> Specialist Training
> >>> <http://www.javaspecialists.eu/courses/concurrency.jsp> course.
> >>>
> >>> Check it out!
> >>> Thanks
> >>> Victor Grazi
> >>>
> >>>
> >>> _______________________________________________
> >>> Concurrency-interest mailing list
> >>> Concurrency-interest at cs.oswego.edu <javascript:;>
> >>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >>>
> >>
> >> ------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> Concurrency-interest mailing list
> >> Concurrency-interest at cs.oswego.edu <javascript:;>
> >> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> >>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130417/4332a13a/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Wed, 17 Apr 2013 09:19:07 -0700
> From: Nathan Reynolds <nathan.reynolds at oracle.com <javascript:;>>
> To: concurrency-interest at cs.oswego.edu <javascript:;>
> Subject: Re: [concurrency-interest] ConcurrentHashMap-Very Strange
>         behavior of ReentrantLock under contention.
> Message-ID: <516ECB7B.4030806 at oracle.com <javascript:;>>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> What version of JDK are you using?  JDK 8 has or will have a new version
> of ConcurrentHashMap.
>
> Nathan Reynolds
> <http://psr.us.oracle.com/wiki/index.php/User:Nathan_Reynolds> |
> Architect | 602.333.9091
> Oracle PSR Engineering <http://psr.us.oracle.com/> | Server Technology
> On 4/17/2013 6:31 AM, Mudit Verma wrote:
> > Hi All,
> >
> > I recently performed a scalability test (very aggressive and may be
> > not practical, anyhow) on put operation of ConcurrentHashMap.
> >
> > Test: Each thread is trying to put (Same Key, Random Value) in HashMap
> > in a tight loop. Therefore, all the threads will hit the same location
> > on hashMap and will cause contention.
> >
> > What is more surprising is, when each thread continue to do another
> > put one after the other, avg time taken in one put operation is lesser
> > than when a thread do some other work between two put operations.
> >
> > We continue to see the increase in per operation time by increasing
> > the work done in between.  This is very counter intuitive. Only after
> > a work of about 10,000 - 20,000 cycles in between, per op time comes
> > down.
> >
> > When I read the code, I found out that put op first try to use CAS to
> > aquire the lock(64 times on multicore), only if it could not acquire
> > the lock on segment through CASing, it goes for ReentrantLocking
> > (which suspend threads .. ).
> >
> > We also tweaked, the number of times CAS (from 0 to 10,000) is used
> > before actually going for ReentrantLocking.   Attached is the graph.
> >
> > One interesting thing to note. As we increase the work between two
> > ops, locking with 0 CAS (pure ReentrantLocking) seems to be worst
> > affected with the spike. Therefore, I assume that, spike comes from
> > ReentractLocking even when there is a mixture of two (CAS+Lock).
> >
> > Code Skeleton: For each Thread
> >
> > While() {
> >   hashMap.put(K,randomValue);     // K is same for each thread
> >   ThinkTime();    < Ranging from 0 Cycles to 1 million Cycles>
> >
> > }
> >
> >  Machine: 48 core NUMA
> > Threads used:  32 (each one is pinned to a core).
> > #ops: In total 51200000 (each thread with 160000 ops)
> >
> > That's like saying, if I do something else in between my operations
> > (upto a limit), contention will increase.  Very strange.
> >
> > Does anyone of you know why is it happening?
> >
> >
> > _______________________________________________
> > Concurrency-interest mailing list
> > Concurrency-interest at cs.oswego.edu <javascript:;>
> > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130417/7d94d447/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu <javascript:;>
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
> End of Concurrency-interest Digest, Vol 99, Issue 41
> ****************************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20130417/08e671ab/attachment-0001.html>


More information about the Concurrency-interest mailing list