Re: CF: crossfire design

[Scott Wedel <scott@campy.Tymnet.COM>]

Steve,
No offense intended, but I have been writing multi-threaded C code
for at least four years now and I think it is easier than writing
single threaded applications.  As long as you very clearly keep various
logic within a thread and pass events between threads (as compared to
keeping the event within a thread and possibly forcing yourself to grab
a series of locks before doing the intended action) then it is
relatively easy.  That is where people get themselves screwed up by
having every subroutine callable from every thread.  The right way to do
it is to have threads that do specific things and so if another thread
wants that action done then it pass the event to another thread and
signals it to act.  And events passed are not required to be acted upon
immediately or risk deadlock, but put upon a queue.  People get 
themselves into trouble by thinking about machine time delays as 
compared to human time.  Maybe threading will make something happen
after something else that CPU time could argue event is now out of
sequence, but which event really should have occurred first is
dependent on many otherside factors (net delays and so on) and so
application (ie CF) is okay just dealing with events as they come up
and not worrying much about microsecond latency and timing issues.

While I have not worked on CF recently, I have worked on it enough in
the past to know that a map is pretty well isolated from all other
events on other maps.  Moving an object between maps would require
synchronization as would communications between members of a party.  But
that is it.  Player being a thread would mostly just be some checks to
see if current event can be handled locally within the thread or if
event needs to be passed to map thread.

Fork() sucks because it is then so much harder to pass info between
processes.

Lastly, I may be nuts, but apparently I have been so for quite a while
now and it is easier than the alternatives.  I am not saying that
multi-threading CF is merely a weekend project do be done between
watching sporting events, but it is something that could reasonably be
done in 200 hours of programming effort.

							sdw
							
ps. The multi-threaded stuff I write is not merely some stuff of
personal interest, but to be up for months on end and servicing millions
of users between restarts.  So any threading bugs would likely be seen
and hence I am talking about something I am knowledgeable.  I am not
claiming to be some god of threaded applications, but I think by giving
up theoretical optimizations and by keeping it simple which could even
be called stupid then it'll work well.  The performance gains are not
in the microsecond range of being able to handle this or that slightly
faster, but in the occasional larger chunk of time where being single
threaded made quickly responding to an event too difficult to fully
implement.

> Date: Fri, 23 Jul 1999 01:28:08 +0000
> From: Steve Fink <sfink@digital-integrity.com>
> X-Accept-Language: en
> Mime-Version: 1.0
> To: Scott Wedel <scott@campy.tymnet.com>
> Cc: sutton@bay.cats.ohiou.edu, crossfire@ifi.uio.no
> Subject: Re: CF: crossfire design
> Content-Transfer-Encoding: 7bit
> 
> > A thread per map would minimize contention issues since there is 
very
> > little on a map that affects other maps.  It might also be worth it 
to
> > have a thread per each player as a frontend to client which handles
> > non map actions (such as inventory/equipment, eating, and so on) and
> > passes player events to and from the map thread.
> > 
> > Threads are also a wonderful way to simplify logic since you can 
write
> > single user code that blocks waiting for input (for example) and 
simply
> > works it's way through a routine as compared to multi-user code 
which
> > has to save info/states and be able to leave, handle other users and
> > then continue handling this user.
> 
> No offense, but you're nuts. ;) Multithreaded code is nearly always
> much, much more difficult to deal with. It's the sort of thing where 
you
> start out thinking "gee, I'm not sharing much of anything, it should 
be
> a no brainer" and throwing in a little bit of locking, and then go to
> "oops, there's one rare case where this will deadlock, better go throw
> in a little more synchronization", to "crap, lemme start over and 
design
> this thing right", to "aha! I've got a beautiful design that I've
> practically *proved* is correct with almost no overhead in the common
> case, and with only half a dozen synchronization operations", to "oh
> damn, I didn't think that would ever happen. But surely it's a small
> change to prevent this stupid little deadlock", to "no, these
> incremental fixes will never work, I'm gonna have to redesign the 
whole
> thing, but this time I'll get it right", to "now why the hell did I 
ever
> start this in the first place?"
> 
> It's *always* simple when you think about it at a high level. And in 
my
> experience and that of many people I know, it's always incredibly 
hairy
> by the time you're done implementing it. Now add to that the problems
> with getting the debugger to work with it, profilers to do the right
> thing, etc. (and remember, you're raising the bar for everyone _else_
> who might want to hack on the code, or just submit detailed bug
> reports.)
> 
> Now Java people live in a special world where it actually *is* 
possible
> to do some nontrivial threading without diving off the deep end. But 
if
> you talk to experienced Java programmers who actually gained 
significant
> performance benefit from it, you'll hear pretty much the same story.
> (The great success of Java threading, IMHO, is that you actually *can*
> get some logic simplifications out of threading without trying very
> hard.)
> 
> IMHO, threads in C should be reserved for very small, isolated 
sections
> of code that really need the performance gain. And even then, you'd be
> surprised at the number of times that fork() will give you 90% of what
> you want with 10% of the headaches. It can even improve the system
> architecture -- threading tends to lead you to a model where lots of
> things diddle with the shared state; multiprocessing tends to make you
> separate out the shared stuff into a single piece with a well-defined
> API for the autonomous processes.
> 
> Just my 2 cents.
> -
> [you can put yourself on the announcement list only or unsubscribe 
altogether
> by sending an email stating your wishes to 
crossfire-request@ifi.uio.no]

-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to crossfire-request@ifi.uio.no]