Author: toad
Date: 2008-05-21 13:44:18 +0000 (Wed, 21 May 2008)
New Revision: 20014
Modified:
branches/db4o/freenet/src/freenet/client/async/ClientRequestSchedulerCore.java
Log:
Don't lock here, we lock in CRS.
Modified:
branches/db4o/freenet/src/freenet/client/async/ClientRequestSchedulerCore.java
===================================================================
---
branches/db4o/freenet/src/freenet/client/async/ClientRequestSchedulerCore.java
2008-05-21 13:43:39 UTC (rev 20013)
+++
branches/db4o/freenet/src/freenet/client/async/ClientRequestSchedulerCore.java
2008-05-21 13:44:18 UTC (rev 20014)
@@ -106,11 +106,11 @@
return -1;
}
- // LOCKING: Life is a good deal simpler if we just synchronize on
(this).
+ // LOCKING: ClientRequestScheduler locks on (this) before calling.
// We prevent a number of race conditions (e.g. adding a retry count
and then another
// thread removes it cos its empty) ... and in addToGrabArray etc we
already sync on this.
// The worry is ... is there any nested locking outside of the
hierarchy?
- synchronized SendableRequest removeFirst(int fuzz, RandomSource random,
OfferedKeysList[] offeredKeys, RequestStarter starter,
ClientRequestSchedulerNonPersistent schedTransient) {
+ SendableRequest removeFirst(int fuzz, RandomSource random,
OfferedKeysList[] offeredKeys, RequestStarter starter,
ClientRequestSchedulerNonPersistent schedTransient) {
// Priorities start at 0
if(logMINOR) Logger.minor(this, "removeFirst()");
boolean tryOfferedKeys = offeredKeys != null &&
random.nextBoolean();
