Styjun

Why did the soldiers of the North disobey Jon?

Why was my Canon Speedlite 600EX triggering other flashes?

What is this old US Air Force plane?

Source of the Wildfire?

Is 12 minutes connection in Bristol Temple Meads long enough?

Uh oh, the propeller fell off

Is there any good reason to write "it is easy to see"?

Where to find every-day healthy food near Heathrow Airport?

Why does SSL Labs now consider CBC suites weak?

How do I identify the partitions of my hard drive in order to then shred them all?

Why didn't the Avengers use this object earlier?

Did galley captains put corks in the mouths of slave rowers to keep them quiet?

Why are BJTs common in output stages of power amplifiers?

How to disable Two-factor authentication for Apple ID?

How might a landlocked lake become a complete ecosystem?

How to redirect stdout to a file, and stdout+stderr to another one?

Motorola 6845 and bitwise graphics

How to cope with regret and shame about not fully utilizing opportunities during PhD?

Would life always name the light from their sun "white"

Will the volt, ampere, ohm or other electrical units change on May 20th, 2019?

Offered a new position but unknown about salary?

Why can't I share a one use code with anyone else?

A case where Bishop for knight isn't a good trade

How to make a not so good looking person more appealing?

Is it possible to get a deadlock with ConcurrentHashMap in this circumstance?

Does a finally block always get executed in Java?What's the difference between ConcurrentHashMap and Collections.synchronizedMap(Map)?How to get an enum value from a string value in Java?Are there any drawbacks with ConcurrentHashMap?Possible deadlock in C++/boost/threadLock for JavaMEHow to wait for data with ReentrantReadWriteLock?ReentrantReadWriteLock. read and write acquire priorityHow to update 2 objects atomically in a lock-free manner?Documentation contradictions about ReentrantReadWriteLock. Does eventually write lock has priority over read lock or not in fair mode?

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;

8

2

I'm reading the source code of ConcurrentHashMap in JDK8, notice that TreeBin uses a 'read-write' lock to prevent concurrent read and write.

Read threads will go through TreeNodes if there's no concurrent write thread trying to modify the tree structure. When the 'find' operation is done, read thread may:

(1)'CAS' the lockState and 'unpark' the waiter(writer) thread if it exists.

Following is the 'find()' method in source code.

final Node<K,V> find(int h, Object k) 
 if (k != null) 
 for (Node<K,V> e = first; e != null; ) WRITER)) != 0) (ek != null && k.equals(ek))))
 return e;
 e = e.next;
 
 else if (U.compareAndSwapInt(this, LOCKSTATE, s,
 s + READER)) 
 TreeNode<K,V> r, p;
 try 
 p = ((r = root) == null ? null :
 r.findTreeNode(h, k, null));
 finally WAITER) && (w = waiter) != null)
 LockSupport.unpark(w);
 
 return p;
 
 
 
 return null;
 

on the other hand, writer thread may:

• (2) adding the WAITER state to lockState with 'CAS' operation.




• (3) set itself to waiter variable.




• (4) 'park' itself.

here's the writer's code:

 private final void contendedLock() 
 boolean waiting = false;
 for (int s;;) 
 if (((s = lockState) & ~WAITER) == 0) 
 if (U.compareAndSwapInt(this, LOCKSTATE, s, WRITER)) 
 if (waiting)
 waiter = null;
 return;
 
 
 else if ((s & WAITER) == 0) 
 if (U.compareAndSwapInt(this, LOCKSTATE, s, s 
 else if (waiting)
 LockSupport.park(this);
 
 

HERE IS MY CONFUSION:

If the four operation above run in this order (2) (1) (3) (4), the operation (1) won't unpark anything because 'waiter' was null at that moment.

Then the waiter will park forever without anyone who can unpark it.

The subsequent writes will be all blocked on the intrinsic lock held by the 'parked' thread.

IS THIS A CHANCE OF DEADLOCK ?

I'm really confused about this. I think perhaps I've missed something in the source code. Need your help if you are familiar with it.

java deadlock java.util.concurrent concurrenthashmap

share|improve this question

edited Mar 25 at 2:38

Kyne Xiao

asked Mar 23 at 14:28

Kyne XiaoKyne Xiao

411

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Also, can please someone explain to me this line in find: if (((s = lockState) & (WAITER|WRITER)) != 0)? Why there is no synchronization here and in its block?
  
  – dyukha
  Mar 23 at 14:44
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @dyukha It means if any waiter or writer here, just go through the tree by 'next' references (like a linked-list). Because every time you add a node into the linked-list, you actually add it at the 'first' position which does not disturb your read threads to go through the other nodes in the list. So no locks needed here
  
  – Kyne Xiao
  Mar 23 at 15:43
  

  
  
  
  

add a comment | 

8

2

I'm reading the source code of ConcurrentHashMap in JDK8, notice that TreeBin uses a 'read-write' lock to prevent concurrent read and write.

Read threads will go through TreeNodes if there's no concurrent write thread trying to modify the tree structure. When the 'find' operation is done, read thread may:

(1)'CAS' the lockState and 'unpark' the waiter(writer) thread if it exists.

Following is the 'find()' method in source code.

final Node<K,V> find(int h, Object k) 
 if (k != null) 
 for (Node<K,V> e = first; e != null; ) WRITER)) != 0) (ek != null && k.equals(ek))))
 return e;
 e = e.next;
 
 else if (U.compareAndSwapInt(this, LOCKSTATE, s,
 s + READER)) 
 TreeNode<K,V> r, p;
 try 
 p = ((r = root) == null ? null :
 r.findTreeNode(h, k, null));
 finally WAITER) && (w = waiter) != null)
 LockSupport.unpark(w);
 
 return p;
 
 
 
 return null;
 

on the other hand, writer thread may:

• (2) adding the WAITER state to lockState with 'CAS' operation.




• (3) set itself to waiter variable.




• (4) 'park' itself.

here's the writer's code:

 private final void contendedLock() 
 boolean waiting = false;
 for (int s;;) 
 if (((s = lockState) & ~WAITER) == 0) 
 if (U.compareAndSwapInt(this, LOCKSTATE, s, WRITER)) 
 if (waiting)
 waiter = null;
 return;
 
 
 else if ((s & WAITER) == 0) 
 if (U.compareAndSwapInt(this, LOCKSTATE, s, s 
 else if (waiting)
 LockSupport.park(this);
 
 

HERE IS MY CONFUSION:

If the four operation above run in this order (2) (1) (3) (4), the operation (1) won't unpark anything because 'waiter' was null at that moment.

Then the waiter will park forever without anyone who can unpark it.

The subsequent writes will be all blocked on the intrinsic lock held by the 'parked' thread.

IS THIS A CHANCE OF DEADLOCK ?

I'm really confused about this. I think perhaps I've missed something in the source code. Need your help if you are familiar with it.

java deadlock java.util.concurrent concurrenthashmap

share|improve this question

edited Mar 25 at 2:38

Kyne Xiao

asked Mar 23 at 14:28

Kyne XiaoKyne Xiao

411

• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  Also, can please someone explain to me this line in find: if (((s = lockState) & (WAITER|WRITER)) != 0)? Why there is no synchronization here and in its block?
  
  – dyukha
  Mar 23 at 14:44
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  @dyukha It means if any waiter or writer here, just go through the tree by 'next' references (like a linked-list). Because every time you add a node into the linked-list, you actually add it at the 'first' position which does not disturb your read threads to go through the other nodes in the list. So no locks needed here
  
  – Kyne Xiao
  Mar 23 at 15:43
  

  
  
  
  

add a comment | 

I'm reading the source code of ConcurrentHashMap in JDK8, notice that TreeBin uses a 'read-write' lock to prevent concurrent read and write.

Read threads will go through TreeNodes if there's no concurrent write thread trying to modify the tree structure. When the 'find' operation is done, read thread may:

(1)'CAS' the lockState and 'unpark' the waiter(writer) thread if it exists.

Following is the 'find()' method in source code.

final Node<K,V> find(int h, Object k) 
 if (k != null) 
 for (Node<K,V> e = first; e != null; ) WRITER)) != 0) (ek != null && k.equals(ek))))
 return e;
 e = e.next;
 
 else if (U.compareAndSwapInt(this, LOCKSTATE, s,
 s + READER)) 
 TreeNode<K,V> r, p;
 try 
 p = ((r = root) == null ? null :
 r.findTreeNode(h, k, null));
 finally WAITER) && (w = waiter) != null)
 LockSupport.unpark(w);
 
 return p;
 
 
 
 return null;
 

on the other hand, writer thread may:

• (2) adding the WAITER state to lockState with 'CAS' operation.




• (3) set itself to waiter variable.




• (4) 'park' itself.

here's the writer's code:

 private final void contendedLock() 
 boolean waiting = false;
 for (int s;;) 
 if (((s = lockState) & ~WAITER) == 0) 
 if (U.compareAndSwapInt(this, LOCKSTATE, s, WRITER)) 
 if (waiting)
 waiter = null;
 return;
 
 
 else if ((s & WAITER) == 0) 
 if (U.compareAndSwapInt(this, LOCKSTATE, s, s 
 else if (waiting)
 LockSupport.park(this);
 
 

HERE IS MY CONFUSION:

If the four operation above run in this order (2) (1) (3) (4), the operation (1) won't unpark anything because 'waiter' was null at that moment.

Then the waiter will park forever without anyone who can unpark it.

The subsequent writes will be all blocked on the intrinsic lock held by the 'parked' thread.

IS THIS A CHANCE OF DEADLOCK ?

I'm really confused about this. I think perhaps I've missed something in the source code. Need your help if you are familiar with it.

java deadlock java.util.concurrent concurrenthashmap

share|improve this question

edited Mar 25 at 2:38

Kyne Xiao

asked Mar 23 at 14:28

Kyne XiaoKyne Xiao

411

final Node<K,V> find(int h, Object k) 
 if (k != null) 
 for (Node<K,V> e = first; e != null; ) WRITER)) != 0) (ek != null && k.equals(ek))))
 return e;
 e = e.next;
 
 else if (U.compareAndSwapInt(this, LOCKSTATE, s,
 s + READER)) 
 TreeNode<K,V> r, p;
 try 
 p = ((r = root) == null ? null :
 r.findTreeNode(h, k, null));
 finally WAITER) && (w = waiter) != null)
 LockSupport.unpark(w);
 
 return p;
 
 
 
 return null;
 

 private final void contendedLock() 
 boolean waiting = false;
 for (int s;;) 
 if (((s = lockState) & ~WAITER) == 0) 
 if (U.compareAndSwapInt(this, LOCKSTATE, s, WRITER)) 
 if (waiting)
 waiter = null;
 return;
 
 
 else if ((s & WAITER) == 0) 
 if (U.compareAndSwapInt(this, LOCKSTATE, s, s 
 else if (waiting)
 LockSupport.park(this);
 
 

share|improve this question

edited Mar 25 at 2:38

Kyne Xiao

asked Mar 23 at 14:28

Kyne XiaoKyne Xiao

411

share|improve this question

edited Mar 25 at 2:38

Kyne Xiao

asked Mar 23 at 14:28

Kyne XiaoKyne Xiao

411

asked Mar 23 at 14:28

Kyne XiaoKyne Xiao

411

asked Mar 23 at 14:28

Kyne XiaoKyne Xiao

411