[MUD-Dev] Re: TECH: Distributed Muds

[J C Lawrence]

On Thu, 26 Apr 2001 22:02:21 -0700 
Steven Fleischaker <kuvasza at winterreach.com> wrote:

> From: J C Lawrence

>> I've never liked the base concept of a select() looping process
>> that tried to do real work between select() calls.  It can work
>> to be sure, but it has always smelled of playing with fire.

>> I prefer having a thread dedicated to socket IO, pulling in and
>> buffering the IO as received, and then handling compleated blocks
>> off to one or more queues (depends on whether you do pre-sorts)
>> for the other game systems to pick up and process appropriately.
>> There are several advantages, not the least of which is that you
>> decouple your command/entry model from your processing model.

> The little exposure I've had to multiple threads has left me
> feeling that working with multiple threads is like building a
> swiss clock.  If you don't have some idea of what you're doing,
> get it just right, then the gears start to mesh, you start hearing
> grinding noises, and your app or your whole system just crawls.  

Yup.  This is the basic problem of not designing your data flow
model properly (or, depending on how you look at it, not designing
your segmentation model well).  Everybody who has messed with
threads has been there.  Some, like Java, still are.

> I played with it, got some things out of it, mostly have a few
> books sitting on my shelf for when I have the time to invest in
> learning how to do it well.

The basic lesson I learned is to keep it simple.  Use threads to
build simple asynchronous systems and carefully map out all your
intersection and synchronisation points before you get there.

> Is there some semi-optimal or conventional approach to handling
> this sort of thing?

Threads, like multi-processing, require care.  The basic design of
threaded apps isn't that different to the basic design of threaded
OS kernels, or of multi-processing systems with high shared
memory/IPC use.  It just requires a little more delicacy as the
opportunity for silliness is much more tempting and ever present.

>   1) start a listen thread (listen for new connects, process IO)
>   for all channels OR start a separate thread for each connection?

>   2) start (a) main game thread(s)

>   At intervals (guidelines for responsiveness.. 10 ms?) enter/use
>   critical sections to cause both threads to synchronize, swap
>   information, exit critical sections/let each thread go their
>   merry way?

I've generally retreated to using threaded in the following two
cases:

  1) I have an operation that is significant disjoint from the
  process flow, and which has a significant runtime.  This is
  essentially the normal multi-processing case, except that the
  shared context is high enough to make multi-processing
  unattractive.  

  2) I have a complex item or sub-system which is difficult to make
  thread safe, but which I need to operate from multiple threads.
  Rather than wrap the accessor APIs in mutexes, I'll wrap a thread
  over the subsystem and throw in a message passing layer, allowing
  the thread to do its own internal message resolution scheduling.
  (This is particularly attractive when you're then interfacing to
  an external subsystem which itself operates asynchronously or out
  of order).

> Do you keep all the IO buffers in one thread, or do you keep
> buffers in both threads?

Seeing as threads share code and data segments, I just hand pointers
into the heap about between threads by using an external data
structure (in the above case a FIFO) which can be easily made thread
safe.  If I really need to do buffer copies between the threads, why
not drop the thread and use a distinct seperate process with a
message queue?

> In Win-NT/2k is there an optimal way to halt a thread, pause N
> milliseconds in clock time, then pick it back up without bogging
> your thread down in endless calls to a time command?
...
> Also, at least in Win-NT, there don't seem to be a lot of
> inexpensive, thread-safe databases.

I can't comment on the Windows end of the problem as I've not used
the platform, let alone programmed under it.

--
J C Lawrence                                       claw at kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev