[MUD-Dev] Question about multithreaded servers

[Fabian]

> -----Original Message-----
> From: ola at ifi.uio.no [mailto:ola at ifi.uio.no]On Behalf Of Ola Fosheim
>
> Nick Shaffner wrote:
> > >but I'm worried about deadlocks because
> > >I want objects locked during the whole script so nothing can be changed on
> > >me.
> >
> >     IMHO, this is the root of your problem (locking objects for the whole
> > script).  By nature, deadlocks are far more likely to occur when you have
> > entire objects locked, even when they don't need to be.  In general, you
> > should strive to hold as few object locks as possible for as short a period
> > as possible - though even then you will still get the occasional deadlock.
>
> I don't get this.  Maybe I have misinterpreted something?  It is rather
> obvious that if you acquire all the limited resources you need for the
> rest of the script in one go (an atomic operation) then a deadlock is
> impossible (provided that your script eventually terminates).
> Starvation is another issue, of course.

This is something I've been thinking about more, after the other replies.
I guess the problem is that I wanted to have a command in the script that
would arbitrarily be able to grab out-of-area(And out of thread) objects
for manipulation.  If all the resources were aquired before the script
started execution instead, it would be pretty easy to take care of.

> I'm not convinced that message passing (events) alleviates the basic
> synchronization problem, but you seemed to suggest that? Care to explain
> how you would do this in an elegant and practical eventengine? Simple
> example: "consume two different resources administered by two different
> entities, but only if you can get both". It is obviously not to
> difficult to come up with some solution to this simple example, but I
> can't think of any attractive solution.
> 
> In a real-time programming environment I would assume that a rollback
> scheme is the most attractive solution, basically because you cannot
> prevent screw ups in a situation like that. You have to be able to cover
> situations where a script doesn't terminate etc. Without rollback you
> have to restrict yourself to a design where only trivial transformations
> are possible. (non-trivial being custom transformations where the
> consumption of one or more resources must result in the production of
> some other resource for the universe to remain consistent). One obvious
> advantage with a functional (transaction  like) approach is that you can
> allow users more freedom and assert that the universe invariants are not
> violated before committing them rather than limiting the basic operators
> they have access to.

I wasn't planning on having a fully transactional-based system, or
otherwise, that is surely the most attractive and elegant approach.  I may
just have to cut that ability out, or find a way to reorganize it where it
will fail gracefully if a lock attempt times-out.  I suppose just by making
a simple requirement that all objects must be secured at the begining of the
script would take care of that.  So far the rest of it will work wonderfully.
I have a very small number of locks, and objects are arranged to not be
codependant on eachother.  All event-based also.  Thanks for all the input!

- Fabian




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