Event handling (was: request for comments)

[s001gmu at nova.wright.edu]

On Thu, 15 Jan 1998, JC Lawrence wrote:

> On Mon, 12 Jan 1998 07:43:01 PST8PDT 
> s001gmu <s001gmu at nova.wright.edu> wrote:
> 
> > On Sun, 11 Jan 1998, JC Lawrence wrote:

[...]

> >> Certainly.  You create an event chain (as above) which iteratively
> >> saps the character's strength and vitality.  Should that process
> >> happen to kill the character (strength == 0?) then this will be
> >> noticed by the normal methods of the character object (probably in
> >> the accessor for the strength attribute) and processed from there.
> 
> > As I understand it, the only difference is that he shortcuts the
> > event chain by having the running thread (process in his terms)
> > handle all of the delays by going to sleep, rather than scheduling a
> > new event to go off X ticks down the road.
 
[snip pros: easy interrupts ... ]

> There is a significant implication in this system however.  It
> effectively requires that you use a locking model, as to not use a
> locking model would have most sleeping threads fail due to other more
> rapidly commiting threads interfering with their data references.
> Conversely, if you do go for a locking system the problem is then
> preventing the system from bogging down to a worse-than serial
> execution case as the events all contend and lock-wait for shared
> data.

I disagree.  I don't see either as being implied.  As long as you don't
grab the lock (or the timestamp on the data for lockless), and then go to
sleep, you're fine.    Minimizing the critical section execution time is
the best way to avoid collisions, and putting a wait(), or sleep(), or
pthread_cond_wait() function call inside a critical section is.. well..
less than intelligent.  Release all locks, sleep, wake up, grab locks,
execute, release locks, go back to sleep.  For lockless, sleep, wakeup,
grab timestamp, execute, C&C, sleep.  He would still have to imitate an
event chain, but would rather spend his time in a thread sleeping than on
a cpu scheduling events.

-Greg