[concurrency-interest] RRWL with 'bad' Thread.getId() implementations

Chris Dennis chris.w.dennis at gmail.com
Wed Jun 26 08:58:00 EDT 2013


There is special logic in place in RRWL (firstReader/firstReaderHoldCount)
to optimize the uncontended read lock scenario, this is why you need to have
the an additional thread to push you past this logic and expose the issue
with cachedHoldCounter.

On 6/26/13 8:32 AM, "Valentin Kovalenko" <valentin.male.kovalenko at gmail.com>
wrote:

Aleksey Shipilev wrote: >>Now that's a good example!
I think we don't actually need three threads in order to reproduce the bug.
The following example with only two threads do the same (allows us to invoke
ReentrantReadWriteLock.ReadLock.unlock() from the thread that doesn't hold
the read lock):

public class Main {
       public static void main(String[] args) throws InterruptedException {
             final ReentrantReadWriteLock lock = new
ReentrantReadWriteLock();
             Thread t1 = new LegalThread(1) {
                    @Override
                    public void run() {
                           try {
                                  lock.readLock().lock();
                           } catch (Exception e) {
                                  e.printStackTrace();
                           }
                    }
             };

             t1.start();
             t1.join();
             
             Thread t2 = new LegalThread(t1.getId()) {// t1 was terminated;
according to the Thread.getId() specification one can reuse id of t1
             //Thread t2 = new LegalThread(2) { //use this line of code to
break the trick
                    @Override
                    public void run() {
                           try {
                                  lock.readLock().unlock();// the trick
                                  System.out.println("the trick was
successfully performed");
                           } catch (Exception e) {
                                  e.printStackTrace();
                           }
                    }
             };

             t2.start();
             t2.join();
       }

       static class LegalThread extends Thread {
             private final long id;

             public LegalThread(long id) {
                    this.id <http://this.id>  = id;
             }

             @Override
             public long getId() {
                    return id;
             }
       }
}

I also want to note that documentation of the method
ReentrantReadWriteLock.ReadLock.unlock() doesn't specify that it can throw
IllegalMonitorStateException if the thread doesn't hold the read lock, while
documentation of the method Lock.unlock() specifies that such a restriction
is an implementation detail and it _must_  be documented. So for me it seems
like documentation of the method ReentrantReadWriteLock.ReadLock.unlock()
should also be improved. Am I right?
_______________________________________________ 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/20130626/093f5251/attachment-0001.html>


More information about the Concurrency-interest mailing list