[MUD-Dev] Question about threads.

Sean K sean at hoth.ffwd.cx
Thu Feb 14 12:22:20 CET 2002


On Wed, 13 Feb 2002, Anderson, David wrote:

> 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 haven't found sockets to ever deadlock me, as long as I set the
> sotimeout (socket timeout) to 200 miliseconds.

I think that's a fairly new addition to Java.  Previously, the
Socket class was a child of the Thread class -- so you were stuck
with one thread per connection.
 
> 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?

Ideally, there should only be a very few active threads in your
server at any given time.  That also means that your application may
have quite a few sleeping threads as well.  As you say, the real
point of threads is to use them for jobs that only happen
periodically, or do something that may block for a while
(reading/writing a file, database operations, socket operations,
etc).  Designing a multithreaded system takes some careful thought,
as the more places your threads interact (synchronization points),
the more difficult things become, and the slower everything is
likely to run.

Nothing is free.  You are stuck with N CPU cycles regardless of how
many threads you're using.  Provided you're not on a multiprocessor
machine, I'd use threads judiciously.  Whenever you need to do
something that doesn't cynchronize well with the main flow of your
program or that you've got to wait on, consider putting it in
another thread.

_______________________________________________
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