[concurrency-interest] New version of Java Concurrent Animated

Nathan Reynolds nathan.reynolds at oracle.com
Wed Apr 17 12:15:02 EDT 2013


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
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>      
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> 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.html>


More information about the Concurrency-interest mailing list