db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "NetworkServerSessionManagement" by BryanPendleton
Date Sat, 03 Jun 2006 16:16:34 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by BryanPendleton:

The comment on the change is:
Added section on benign wakeups and notifyAll

  and decrementing logic in {{{getNextSession()}}} handle all the maintenance
  of this counter.
+ == Benign wakeups and notifyAll ==
+ There is a standard convention for thread programming, which dates back
+ to Andrew Birrell's classic paper,
+ [http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/SRC-035.pdf "An Introduction to
Programming with Threads"]
+ for handling the waiting and waking up of threads.
+ As Birrell explains (pages 14-15), threads which are waiting on a resource
+ should always be coded as:
+   {{{WHILE NOT expression DO Thread.Wait(m,c) END;}}}
+ You will note that the {{{getNextSession()}}} method is already coded in
+ the correct style, which is good.
+ When the wait loop is coded in this fashion, Birrell explains, one benefit is (p. 15):
+    A final advantage of this convention is that it allows for simple 
+    programming of calls to “Signal” or “Broadcast”—extra wake-ups are benign.

+    Carefully coding to ensure that only the correct threads are awoken is now 
+    only a performance question, not a correctness one (but of course you must 
+    ensure that at least the correct threads are awoken).
+ Here is where there is a slight issue in the NetworkServer code. In the 
+ {{{runQueueAdd()}}} method, note that we currently issue {{{runQueue.notify()}}}.
+ This means that we are waking up at most one thread to go handle the newly-queued
+ Session.
+ Unfortunately, at this point, {{{runQueueAdd()}}} does not have the proper
+ information to be certain that it is waking up the '''correct''' thread. In
+ particular, in the case of a NetworkServer restart, what if some of the waiting
+ threads happened to be "poisoned" (threads that had been closed by the restart code)?
+ If we simply change {{{runQueueAdd()}}} so that it calls {{{notifyAll()}}}, rather
+ than {{{notify()}}}, then everything will still function properly even if the
+ current mix of threads waiting on the runQueue contains both closed threads and
+ non-closed threads. All of those threads will be awoken; one non-closed thread will
+ eventually grab the session and go run it; all the other threads will either
+ detect that they have been closed and break out of getNextSession() or detect that
+ there are no more Sessions to run and go back to sleep.
  == Changing the Session Management code ==
  I think that there are a number of problems in the Session Management code

View raw message