Re: CF: crossfire design

[Steve Fink <sfink@digital-integrity.com>]

> 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]