On 12/15/2014 06:38 PM, Daniel Fuchs wrote:
On 12/12/14 09:56, shanliang wrote:
Updated.
Here is the new version:
http://cr.openjdk.java.net/~sjiang/JDK-8067241/01/
Thanks,
Shanliang
Hi Shanliang,
Your changes looks good to me. WRT using a Phaser, it would
require a careful analysis to asse
On 12/12/14 09:56, shanliang wrote:
Updated.
Here is the new version:
http://cr.openjdk.java.net/~sjiang/JDK-8067241/01/
Thanks,
Shanliang
Hi Shanliang,
Your changes looks good to me. WRT using a Phaser, it would
require a careful analysis to assert that modifying the
locking strategy - espe
Thank you, Daniel!
It is clear now.
Thanks,
Serguei
On 12/12/14 2:15 AM, Daniel Fuchs wrote:
On 12/12/14 10:11, serguei.spit...@oracle.com wrote:
Hi Shanliang,
The fix is good.
Just a side note...
I do not see why the line 98 is needed as no other thread is going to
sync
on the DeadlockTes
On 12/12/14 10:11, serguei.spit...@oracle.com wrote:
Hi Shanliang,
The fix is good.
Just a side note...
I do not see why the line 98 is needed as no other thread is going to sync
on the DeadlockTest object (that is o) that is passed to the BadBoy
constructor:
98 synchronized(o)
Hi Shanliang,
The fix is good.
Just a side note...
I do not see why the line 98 is needed as no other thread is going to sync
on the DeadlockTest object (that is o) that is passed to the BadBoy
constructor:
98 synchronized(o) {
Thanks,
Serguei
On 12/11/14 11:33 PM, shanliang
Daniel Fuchs wrote:
Hi Shanliang,
These two statements are no longer needed and should be removed - as they
are misleading:
64 if (!bb.gotLock) {
65 throw new RuntimeException("Failed to get lock, impossible!");
66 }
81 if (!wb.done) {
82
Hi Shanliang,
These two statements are no longer needed and should be removed - as they
are misleading:
64 if (!bb.gotLock) {
65 throw new RuntimeException("Failed to get lock, impossible!");
66 }
81 if (!wb.done) {
82 throw new Runtime
Hi,
It is a test bug, it is not correct:
while(!wb.done || timeToWait > 0) {
it should be:
while(!wb.done && timeToWait > 0) {
|| should be changed to &&
Another issue is that the waiting time could be not enough (final long
timeout = 2000).
The fix is to remove the waiting time specifi
