[
https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1877:
--------------------------------
Perhaps something like this is a better impl:
{code:java}
public boolean waitFor(long timeout) {
final long timeout_ns=TimeUnit.NANOSECONDS.convert(timeout,
TimeUnit.MILLISECONDS);
lock.lock();
try {
for(long wait_time=timeout_ns, start=System.nanoTime();
!done && wait_time > 0;
wait_time=timeout_ns - (System.nanoTime()-start)) {
try {
System.out.println("wait(" +
TimeUnit.MILLISECONDS.convert(wait_time,TimeUnit.NANOSECONDS) + ")");
cond.await(wait_time,TimeUnit.NANOSECONDS);
}
catch(InterruptedException e) {
;
}
}
return done;
}
finally {
lock.unlock();
}
}
{code}
System.nanoTime() may be in the future
--------------------------------------
Key: JGRP-1877
URL:
https://issues.jboss.org/browse/JGRP-1877
Project: JGroups
Issue Type: Bug
Security Level: Public(Everyone can see)
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.5.1, 3.6
According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed
time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a
time in the future.
Code like the one below might fail:
{code:title=Responses.waitFor()|borderStyle=solid}
public boolean waitFor(long timeout) {
long wait_time;
final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout,
TimeUnit.MILLISECONDS); // ns
lock.lock();
try {
while(!done && (wait_time=target_time - System.nanoTime()) > 0) {
try {
cond.await(wait_time,TimeUnit.NANOSECONDS);
}
catch(InterruptedException e) {
}
}
return done;
}
finally {
lock.unlock();
}
}
{code}
Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future,
and see what impact a future value value could have. Possibly replace with
{{System.currentTimeMillis()}} or the _time service_.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)