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

Nathan Reynolds nathan.reynolds at oracle.com
Tue Jun 25 13:24:05 EDT 2013


The JavaDoc for Thread.getId() says "...thread ID is unique..." so I 
don't think this is a bug in RRWL.  Maybe Thread.getId() should be 
declared final.

We might want to consider going as far as declaring the member field 
"tid" as final.  This could be done via "private long tid = nextThreadID();"

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.

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 6/25/2013 9:50 AM, Chris Dennis wrote:
> Hi All,
>
> While dealing with a customer issue, I ran in to the possibility of
> breaking a RRWL by feeding in Thread instances with colliding thread-ids.
> Inside RRWL the cachedHoldCounter logic assumes that getId() will return a
> unique identifier for a thread.  Do people consider this a bug in RRWL or
> not? (I think it would be agreed that this is also a bug in the
> subclassing of Thread)
>
> Regards,
>
> Chris Dennis
>
> public static void main(String[] args) {
>    final ReentrantReadWriteLock lock = new ReentrantReadWriteLock();
>    final CyclicBarrier barrier = new CyclicBarrier(2);
>      
>    Thread t1 = new EvilThread() {
>      public void run() {
>        try {
>          lock.readLock().lock();
>          barrier.await();
>          //T2 locks
>          barrier.await();
>          //T3 locks
>          //T3 unlocks
>          barrier.await();
>          //T2 unlocks
>          barrier.await();
>          lock.readLock().unlock();
>        } catch (Exception e) {
>          e.printStackTrace();
>        }
>      }
>        
>    };
>    Thread t2 = new EvilThread() {
>      public void run() {
>        try {
>          //T1 locks
>                    barrier.await();
>                    lock.readLock().lock();
>                    barrier.await();
>                    //T3 locks
>                    //T3 unlocks
>                    barrier.await();
>                    lock.readLock().unlock();
>                    barrier.await();
>                    //T1 unlocks
>        } catch (Exception e) {
>          e.printStackTrace();
>        }
>      }
>        
>    };
>    Thread t3 = new EvilThread() {
>      public void run() {
>        try {
>          //T1 locks
>          barrier.await();
>                    //T2 locks
>                    barrier.await();
>                    lock.readLock().lock();
>                    lock.readLock().unlock();
>                    barrier.await();
>                    //T2 unlocks
>                    barrier.await();
>                    //T3 unlocks
>        } catch (Exception e) {
>          e.printStackTrace();
>        }
>      }
>        
>    };
>      
>    t1.start();
>    t2.start();
>    t3.start();
>    }
>
>    
>    static class EvilThread extends Thread {
>    public long getId() {
>      return 42L;
>    }
>    }
>
>
> _______________________________________________
> 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/20130625/4305eeb6/attachment.html>


More information about the Concurrency-interest mailing list