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

Chris Dennis chris.w.dennis at gmail.com
Tue Jun 25 15:54:25 EDT 2013


In a similar vein, the following code doesn't behave like you'd expect
either (although it's arguable as to whether this is a reasonable way for
RRWL to behave in this circumstance).  Note here that this is totally
legal per the getId() contract, because the id doesn't get recycled until
after the join returns.

Chris

  public static void main(String[] args) throws InterruptedException {
    final ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
    final CyclicBarrier barrier = new CyclicBarrier(2);
    
    Thread t1 = new LegalThread(1) {

      @Override
      public void run() {
        try {
          lock.readLock().lock();
          barrier.await();
          //T2a locks
          //T2b unlocks
          barrier.await();
          lock.readLock().unlock();
        } catch (Exception e) {
          e.printStackTrace();
        }
      }
    };
    Thread t2a = new LegalThread(2) {

      @Override
      public void run() {
        try {
          //T1 locks
          barrier.await();
          lock.readLock().lock();
        } catch (Exception e) {
          e.printStackTrace();
        }
      }
      
    };
    
    t1.start();
    t2a.start();
    t2a.join();
    
    Thread t2b = new LegalThread(2) {

      @Override
      public void run() {
        try {
          lock.readLock().unlock();
          barrier.await();
        } catch (Exception e) {
          e.printStackTrace();
        }
      }
      
    };
    t2b.start();
  }
  
  static class LegalThread extends Thread {

    private final int id;
    
    public LegalThread(int id) {
      this.id = id;
    }
    
    @Override
    public long getId() {
      return id;
    }
  }



On 6/25/13 3:24 PM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com> wrote:

>On 06/25/2013 09:24 PM, Nathan Reynolds wrote:
>> The JavaDoc for Thread.getId() says "...thread ID is unique..." so I
>> don't think this is a bug in RRWL.
>
>+1. Intentionally breaking the Thread contract does seem bad.
>
>> I find it very interesting that threadInitNumber and threadSeqNumber are
>> both used in the Thread class.  It seems we only need 1.  It seems that
>> the constructor should use "Thread-" + tid for a thread name.  In fact,
>> the name could read "Thread-10" and the tid could be 7 because there is
>> a race between when the name is generated and the tid is set.  The
>> mismatch probably doesn't matter functionally.  However, it could make
>> it easier for debugging.
>
>In addition, we could finally eliminate those synchronized{} in JDK 8.
>(Since Thread is the primordial class, you can't easily use atomics
>there, but now as we have Unsafe.getAndAdd*... ;)
>
>This looks like a good and simple task for a newcomer to OpenJDK. If
>anyone from the community is interested in prototyping the patch,
>testing it, and pushing through OpenJDK, but does not know where to
>start, PM me ;)
>
>-Aleksey.
>_______________________________________________
>Concurrency-interest mailing list
>Concurrency-interest at cs.oswego.edu
>http://cs.oswego.edu/mailman/listinfo/concurrency-interest




More information about the Concurrency-interest mailing list