[MUD-Dev] Event Scheduling

[J C Lawrence]

On Thu, 10 Feb 2000 12:01:23 -0500 
Phillip Lenhardt <philen at funky.monkey.org> wrote:

> On Tue, Feb 08, 2000 at 10:31:39AM -0800, J C Lawrence wrote:
>> The general intent is that only a small minority of the total
>> number of "events" will ever actually invoke the queing system,
>> and that, further, due to the size and processing capacity of the
>> Executor's thread pool, that the pool of events awaiting
>> execution by threads, will always be small.

> As someone has mentioned, short-circuiting your queue means that
> queued events are running at a lower priority than events that
> bypass the queue.  

No, due to the fact that I run a two part queueing and execution
system.  They do arrive at the Executor slightly faster, but the
difference is really minimal.

  Events come into the Dispatchor, and if they are not ripe, are
  placed in a priority queue to wait until they are ripe (the sort
  key is ripe time).  If the event is ripe, the event is immediately
  released to the Executor.

  One thread handles events arriving at the Dispatchor and another
  thread handles running the Dispatchor's queue and releasing ripe
  events to the Executor.

  The Executor runs its own priority queue where the sort key is a
  priority value.  Events sit in the Executor's event queue waiting
  for a free thread in the thread pool to execute them.  

  Events arriving from the Dispatchor are usually sent with a
  default priority value, but can arrive with a specified higher or
  lower priority value (rare).

  Events that fail C&C and are rescheduled receive increasingly high
  priority values, and will, if the condition persists, eventually
  force the Executor into single-threaded mode with the thread pool
  temporarily put on wait until the high priority task compleats.

All prioritisation is effected by the Executor.  Determination of
what events compleat in what order is explicitly non-deterministic
and in general cannot be guaranteed (see very extensive discussion
of this in the archvies).  

The basic story is that events comete with each other for successful
execution and thus light weight events with minimal working sets and
short execution times will tend to successfully C&C and will thus
process more readily than events with larger working sets and/or
longer execution times who have more risk of contention and thus
failing the C&C.  So yes, such light weight events have an inbuilt
advantage in their short lives.  Call it "better genetics".

Queue short circuiting however affects none of this.  All it does is
remove a little overhead from the Dispatchor's queue insert/remove,
and the thread and context overhead of having to wake the
Dispatchor's delivery thread to handle realeasing the thread to the
Executor versus doing it directly.  Given the fact that arrival
times of events at the Dispatchor are non-deterministic and have no
inter-relevance, the fact that one event is short circuit released,
and the other waits a bit on the Dispatchor's queue is quite
irrelevant.

> That is not necesssarily bad, but I find it undesireable. Adding a
> flag to events such that if the flag is set, it bypasses the queue
> seems like a better solution (ie marking some events "real-time").

Most of my events falls into ths category (eg parsing user commands,
effecting user commands, mobile actions, etc).  It is a tiny
percentage of events which require queueing in the Dispatchor --
thus the short circuit.  I'm not about to build a special flag for
something that is the normal case.

--
J C Lawrence                                 Home: claw at kanga.nu
----------(*)                              Other: coder at kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev