[MUD-Dev] Question about multithreaded servers

[Greg Underwood]

At 09:48 PM 1/18/00 -0800, J C Lawrence <claw at kanga.nu> wrote:
>On Tue, 18 Jan 2000 22:31:50 -0700 
>cg  <cg at ami-cg.GraySage.Edmonton.AB.CA> wrote:
>
>> [Greg Underwood:]
>>>
>>> No, that's not true.  Just because you attempt to lock everything
>>> before you execute the script doesn't mean you avoid deadlocks.
>
>> Perhaps the original writer was assuming that all the locks are
>> acquired at once. An example of that is the SysV locking stuff in
>> some versions of UNIX. It's ugly as sin, but essentially allows
>> you to do a whole mess of lock operations all at once, atomically.

That's a good point... I wasn't aware of that option.  :)  I've been
messing with Linux and Irix threads a lot, but not the real, down'n'dirty
aspects.  However, if portability is ever a desired feature, I'd avoid the
grab 'em all atomically feature.  Besides, always locking in the same order
enforces disciplin in your coding, something you can never have too much
of, /especially/ when you're dealing with threads.  ;)

>That requires you to know the full list of to-be-locked resources in
>advance, something which is not necessarily difficult in an OS
>context with its clearly defined call tree semantics, but can be an
>utter bitch in a MUD.

Very true.  I was assuming that the scripting engine was capable of looking
at the code a bit and figuring out everyone you'd need to lock, prior to
execution.  Building in that look-ahead code would be the trade-off you'd
have to decide on, when deciding if it's really imperative to insure
message delivery in the same order as they are in the code.

>  This is one of the major reasons I went with
>the lockeless model.  Going for a hard lock model looked fraught
>with Oh-damn-I-forgot-about-that's.

yeah, but a transactional model has it's own pile of those, and can result
in code being executed and re-executed, as it attempts to commit the
changes it is making and fails.  I'll leave the discussion at that, since I
recall having this very conversation with you, JC, some time ago.  I'm sure
any interested parties could scrounge the thread out of the archive, if
they wanna get more details on it. ;)

[pulled this from Chris Gray's previous message, since JC didn't include it
in his response]

> I hadn't thought of that - I'll have to go check the stuff at work. I
> likely did it reverse order, just because it looks better to me, but
> possibly not always. Thanks for the tip!

No problem.  The main reason I do it is that it looks better; it makes you
think of the locks as a stack, to which you can only push and pop.  And
again, it encourages disciplin.

-Greg




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev