cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bened...@apache.org
Subject [1/3] git commit: ninja fix comments in SharedExecutorPool
Date Tue, 15 Jul 2014 17:21:30 GMT
Repository: cassandra
Updated Branches:
  refs/heads/trunk 8a5a82b8a -> 1c4768a88


ninja fix comments in SharedExecutorPool


Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/ca431888
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/ca431888
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/ca431888

Branch: refs/heads/trunk
Commit: ca431888efd91bb8a7900c0219bd821744153686
Parents: 0401761
Author: Benedict Elliott Smith <benedict@apache.org>
Authored: Tue Jul 15 18:20:48 2014 +0100
Committer: Benedict Elliott Smith <benedict@apache.org>
Committed: Tue Jul 15 18:20:48 2014 +0100

----------------------------------------------------------------------
 .../cassandra/concurrent/SharedExecutorPool.java | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/cassandra/blob/ca431888/src/java/org/apache/cassandra/concurrent/SharedExecutorPool.java
----------------------------------------------------------------------
diff --git a/src/java/org/apache/cassandra/concurrent/SharedExecutorPool.java b/src/java/org/apache/cassandra/concurrent/SharedExecutorPool.java
index e03ec57..161b326 100644
--- a/src/java/org/apache/cassandra/concurrent/SharedExecutorPool.java
+++ b/src/java/org/apache/cassandra/concurrent/SharedExecutorPool.java
@@ -35,17 +35,22 @@ import static org.apache.cassandra.concurrent.SEPWorker.Work;
  * To keep producers from incurring unnecessary delays, once an executor is "spun up" (i.e.
is processing tasks at a steady
  * rate), adding tasks to the executor often involves only placing the task on the work queue
and updating the
  * task permits (which imposes our max queue length constraints). Only when it cannot be
guaranteed the task will be serviced
- * promptly does the producer have to signal a thread itself to perform the work.
+ * promptly, and the maximum concurrency has not been reached, does the producer have to
schedule a thread itself to perform 
+ * the work ('promptly' in this context means we already have a worker spinning for work,
as described next).
  *
- * We do this by scheduling only if
- *
- * The worker threads schedule themselves as far as possible: when they are assigned a task,
they will attempt to spawn
+ * Otherwise the worker threads schedule themselves: when they are assigned a task, they
will attempt to spawn
  * a partner worker to service any other work outstanding on the queue (if any); once they
have finished the task they
  * will either take another (if any remaining) and repeat this, or they will attempt to assign
themselves to another executor
  * that does have tasks remaining. If both fail, it will enter a non-busy-spinning phase,
where it will sleep for a short
  * random interval (based upon the number of threads in this mode, so that the total amount
of non-sleeping time remains
- * approximately fixed regardless of the number of spinning threads), and upon waking up
will again try to assign themselves
- * an executor with outstanding tasks to perform.
+ * approximately fixed regardless of the number of spinning threads), and upon waking will
again try to assign itself to
+ * an executor with outstanding tasks to perform. As a result of always scheduling a partner
before committing to performing
+ * any work, with a steady state of task arrival we should generally have either one spinning
worker ready to promptly respond 
+ * to incoming work, or all possible workers actively committed to tasks.
+ * 
+ * In order to prevent this executor pool acting like a noisy neighbour to other processes
on the system, workers also deschedule
+ * themselves when it is detected that there are too many for the current rate of operation
arrival. This is decided as a function 
+ * of the total time spent spinning by all workers in an interval; as more workers spin,
workers are descheduled more rapidly.
  */
 public class SharedExecutorPool
 {
@@ -96,4 +101,4 @@ public class SharedExecutorPool
         if (current == 0 && spinningCount.compareAndSet(0, 1))
             schedule(Work.SPINNING);
     }
-}
\ No newline at end of file
+}


Mime
View raw message