[MUD-Dev] Threading and Queues (What Fun)
lynx at lynx.purrsia.com
lynx at lynx.purrsia.com
Mon Feb 17 15:30:08 CET 2003
On Sun, 16 Feb 2003, Ben Chambers wrote:
> I was considering just looping but I feel that it could
> potentially introduce lag into the system. I'm considering a
> system that uses two or three threads and has MySQL as a database.
> The first thread would be input. The second would be for
> processing commands. The first would parse commands and send them
> to the second thread for execution. The second would then put the
> resulting output into a queue which would either be processed by
> input or by a third thread handling output.
Traditionally if there's nothing for a thread to do, it should block
on an event and when another thread adds work to that thread's
queue, it should signal the event. This also allows you to have
many worker threads which can wait on an event. Note that there's a
difference between pthread_cond_signal and pthread_cond_broadcast;
the former wakes up only one thread waiting on an event, the latter
wakes up all threads on that event.
> Will this work as well as I think it might? Any other ideas that
> are easier? Has anyone used threads like this before? What about
> this kind of queue? Any other threading models that might work
> better? What is the best method of getting good performance.
You may find that your MUD will run faster if you cache objects
currently or likely to be used in memory. Then you can periodically
synchronize the changed objects against the database.
Make sure that you're careful about not saving objects
mid-transaction, i.e. if one of your threads is juggling several
objects, you don't want the save to save the state of objects in the
middle, only at the beginning or at the end. Using read/write locks
might work; the semantic would be that once a write lock has been
obtained on an object, it can't be read until the write lock has
been cleared, meaning that whatever transaction was in effect has
been completed. Similiarly, a write lock can't be obtained until
all read locks have been cleared.
-- Conrad
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list