[MUD-Dev] Threading and Queues (What Fun)

&lt &lt
Mon Feb 17 14:37:57 New Zealand Daylight Time 2003

From: "Ben Chambers" <bjchamb at bellsouth.net>

> For the command queue I also want to use it to handle delayed
> events.  Here is the system that I'm considering.  An array that
> has n spaces.  Each space has a pointer to the head of two linked
> lists, delayed actions (for timed actions) and immediate actions.
> The event queue processes from let us say space a of the array
> while the input thread is writing to the immediate actions of
> space a + 1.  This way the only thing that needs to be
> synchronized is the space in the array that is being written to.

Sounds like the event is "chasing" the input.  Technically each
"write" will have to be either atomic or synch'd - if you get a
context swap while you're halfway through your write you could end
up having the event-thread reading an unfinished input or having the
event-read bypass the event-write in extreme circumstances.

A dual-FIFO queue would probably work better in this instance.  One
FIFO for "building up" the inputs and a second FIFO for reading.
When the Input signals completion then its queue-object is passed to
the event-FIFO.  After the event-FIFO is done the used-object is
returned to a free-pool for later use on the Input cycle.

A possibility for "timed" events would be a dual-linked list of FIFO
queues.  As the Input is finished its object is dropped into the
appropriate container/FIFO entry in the array.  Each "tick" of your
system would increment a container-pointer and move those events to
the formal event processing queue.  If you need something to fire 20
ticks out you simply drop it in the 20th container from the current
pointer.  Since it's a linked list, you won't have to worry about
memory allocations or running out of room.  Obviously the size of
the list would have to be determined by you, but given enough memory
you could have quite the timed event list.  "n" events in a given
container would retain their own ordering as well, due to the FIFO
nature of the queue.

The biggest advantage I see to the above ramblings is that you're
only syncing the movement of the queue-objects and not the contents.
This allows for arbitrarily large queue-objects since you're just
pushing pointers and should be fairly fast to minimize possible


MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list