Styjun

What city and town structures are important in a low fantasy medieval world?

How would a physicist explain this starship engine?

Presenting 2 results for one variable using a left brace

US F1 Visa grace period attending a conference

Is there a way to generate a mapping graph like this?

If the Charles SSL Proxy shows me sensitive data, is that data insecure/exposed?

Is there a word for pant sleeves?

Connecting circles clockwise in TikZ

What to call a small, open stone or cement reservoir that supplies fresh water from a spring or other natural source?

Schwa-less Polysyllabic German Noun Stems of Germanic Origin

On a piano, are the effects of holding notes and the sustain pedal the same for a single chord?

Does a windmilling propeller create more drag than a stopped propeller in an engine out scenario?

Best practice for printing and evaluating formulas with the minimal coding

why "American-born", not "America-born"?

How did Jean Parisot de Valette, 49th Grand Master of the Order of Malta, die?

Filter a file list against an integer array?

tikz: 5 squares on a row, roman numbered 1 -> 5

If you attack a Tarrasque while swallowed, what AC do you need to beat to hit it?

Parse a C++14 integer literal

How do you cope with rejection?

Farthing / Riding

Is my company merging branches wrong?

Do seaplanes need to get clearance for takeoff?

Do 'destroy' effects count as damage?

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; ) 
 int s; K ek;
 if (((s = lockState) & (WAITER
 
 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; ) 
 int s; K ek;
 if (((s = lockState) & (WAITER
 
 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; ) 
 int s; K ek;
 if (((s = lockState) & (WAITER
 
 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; ) 
 int s; K ek;
 if (((s = lockState) & (WAITER
 
 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