Nudd ap Mawr wrote:
>
> On Mon, 26 Jan 1998, George wrote:
>
> :On Mon, 26 Jan 1998, Sean Butler wrote:
> :
> :>Has anyone made a modification of circle to use threads? What advantages
> :>do you think they would give? What disadvantages? Would performance
> :>increase or decrease? What areas of the mud would be best benefited from
> :>them and why?
> :
> :Actually, yes I did. The only real advantage in the way I implemented it
> :is that if your MUD gets stuck in an infinite loop or something takes too
> :long (like 2.1 billion dice rolling), the processing thread can be killed.
> :Then it restarts the processing again, but of course, the world may have
> :some inconsistency in it after doing that depending on when it loops. The
> :way I did it is the only way I can think of, you cannot have multiple
> :processing threads because of the 4 global buffers. I basically split it
> :into 'Network I/O' and 'Character Processing' with a backward compatible
> :option if thread creation fails.
>
> Actually you could get around this by using a mutex lock on the global
> variables. Just put a lock infront of all of the critical sections, and
> release the lock when it is safe for those global variables to be
> overwritten.
Problem with that is, that these global buffers are used in nearly
every function within the stock game, and therefore calling mutex or
critical section locks wouldnt give the game much more performance, if
any. Optimally, if not redesigned in an object-oriented structure, you
could avoid global buffer switching and locking by making a similar buffer
for each descriptor, and run a thread for each. Then use local or minimal
global buffers for mobs and the like.
> As far as threads go, probably the best candidate (sp?) for spawning of
> threads would be the ident lookup or dns name resolving. Any other
> threads probably won't help much (ie. hard to document the
> benefits) unless you are running on a multi-processor type system.
Maybe currently using the network I/O threading that George has developed,
plus game-booting threads (ive seen major areas here where it could be
improved), and possibily some disk I/O (still requires a fair amount of
sync'ing tho).
> Basically, with threads you just have to be careful that variables that
> can be used by more than one thread don't get stomped on. And mutex locks
> are the solution for that.
>
Agreed.
> --
> Dez.
>
> void signature () {
> printf ("Praise not the day until evening has come; a woman\n"
> "until she is burnt; a sword until it is tried; a maiden until\n"
> "she is married; ice until it has been crossed; beer until it\n"
> "has been drunk. -- Viking Proverb\n");
> }
>
> +------------------------------------------------------------+
> | Ensure that you have read the CircleMUD Mailing List FAQ: |
> | http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
> +------------------------------------------------------------+
--
Franco Gasperino
Cutting Edge Communications
(509) 444-INET
awe@cet.com
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/15/00 PST