[MUD-Dev] Question about threads.

[Daniel.Harman at barclayscapital.com]

From: Anderson, David [mailto:david.anderson at tfp.com]

> I was wondering about what the purpose of using threads would be,
> since currently I'm in a single loop like Rom, where I process
> every user in turn, and cycle through that over and over.

> I can think of plenty of problems by using threads (IE, the Dragon
> walking through a door that just closed).  What would be the
> benefits?  What are the reasons I should use threads?  And even
> better, if I should use threads, what would be their purpose? One
> thread per user? One thread for users, one for game updates, one
> for mob updates, etc?

I'm not sure how useful this is to you, but I'll outline my design
and reasoning as it may be illustrative. If nothing more, I may get
some useful criticism from list members :)

In my system I have 2 thread pools, and one further worker thread.

Pool 1

  Threads that serve to listen to new client 'logins'. I'm using UDP
  (not TCP), so I need to do this explicitly, and by having a
  seperate pool, it helps me segregate and if necessary throttle the
  log in rate such that it doesn't compromise people already
  connected. Especially as login could be a potentially slow
  operation if looking up records in a database etc.

Pool 2 

  Threads that serve the connected users sockets, handling both
  sending and recieving. When a message arrives, it is unpacked into
  its class (using the pluggable factory pattern) and then put in a
  queue to be processed by the main game thread. The main advantage
  of having a seperate thread pool here is that it should ensure
  that sockets are serviced frequently enough to prevent buffer over
  runs, and also to facilitate the reliable messaging over UDP
  functionality (which I feel is important to encapsulate away from
  game logic).

Main game thread

  Pulls things off the input message queue and acts upon them. Also
  checks the game scheduler (also known as 'event queue') to see if
  anything is due.

[Potential Further Thread/Pool] 

  I haven't decided on this one yet as I'm not at this
  implementation point yet. However, I'm considering another thread
  to talk to the database and manage caching of objects. Essentially
  this would sit in the background loading objects into the cache on
  requested (and predictevly), and persisting them back to the
  database without blocking the main execution thread. Database
  caches tend to be pretty effective these days, so I will have to
  make some performance tests to see the benefit of this - it will
  probably depend to some extent on the complexity of assembling
  objects from the database in terms of instantiation cost and query
  cost. Whether or not it would be a single thread or a pool is also
  uncertain. Having said, with Oracle at least, one needs to make
  lots of async requests to get decent performance.

Dan
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev