[MUD-Dev] C&C and Event Rescheduling

[Miroslav Silovic]

> To an extent however it could reduce responsiveness:
> 
>   Very long event X starts processing.
>   Near the end of X's run: very short event Y starts processing.
>   Y locks resource A.
>   X requests A and dies.
>   
> Didn't you have some sort of age/priority scheme in there to counter
> this?  I seem to remember something such.

Yes, I had a-priory prioritizing in mind. Although I didn't put it down
into any sort of specification, the idea would be that things like
create/destroy/change parents would run with high priority. While these
take relatively long time to complete in some cases, they'll at least
survive other tasks.

> >I consider this a good thing. Remember, you have change_parents
> >function in Cold. When you call it, it guarantees that the database
> >will be consistant after termination. 
> 
> FWLIW I have a similar call, but I don't guarantee consistancy. 
> Instead I rebuild the inheritance tree when an outdated object is
> detected.  This doesn't change the workload much -- it just spreads it
> out over time.

No, the problem we deal with is this: Suppose you have a helpnode, and
some moron decides to reparent it to room. Now this is almost surely
and admin mistake, but this is what then happens: helpnode is tracked
by help indices, and rooms are tracked by their realms. Now if you
/only/ change the inheritance, you have a room in a help index and
a room without its realm. This, of course, is a Bad Thing, because
you have also broken the help index.

The idea, then, is to call destructor method that destroys the helpnode
part of the help node (indidentally removing it from its index) and
calls constructor that does the housecleaning needed to add a consistant
room.

Now do this to a helpnode with 2000 descendants. Each of them is a
helpnode and, well, needs to be cleared.

Of course, this is not very realistic example, but adding parents to
user object may well be very desirable, and if the parent require
some internal state (suppose you're adding combat stats object to user),
Cold will guarantee that the entire hierarchy is properly initialized.

This has *huge* working set, but the alternative of /not/ doing it
caused incredible number of problems in the past (it's utterly
annoying to have, for example, invalid objects in the player database).

> Were I to do this sort of mass munging of the DB by a single event,
> I'd have the event start at one of the higher priority levels --
> potentially even at single-threaded mode.  I can do that.

Right - but it's still good to have it terminate even if the admin
forgot to tune the priority.

> >Actually I intend to reschedule the tasks with random delays,
> >precisely because of this (I believe this solution is standard).
> >Deadlock is improbable, then, because sooner or later things will
> >schedule in the right order, with proper pause between each.
> 
> Random rescheduling is a standard approach, however I wouldn't label
> it a solution.  You might like to do a simulation here.  I suspect
> you'll be surprised by the results.  The problem of this approach is
> that its incredibly sensitive to both the load and to range of the
> random number generated.  
> 
> Specific case:  If the random generation varies by a value which is
> generally far smaller than the specific contending events in question,
> then they'll continue to contend for a long while.  There are other
> nasty cases (a simulation should show you most of the nasty ones).  

I actually intended to double the random delay on each reschedule.
This should take care of most of the problems. But you're quite
right, this will take some experimenting. Mind you, we don't even
have OS-level threading in place (or even in progress) yet. :)

I'm actually interested on your opinion on doubling the delays each
time (well, doubling value 'x', then getting the delay as random(x),
to be more precise).

> >> Aside: Its not distributable, well, not in any sane manner, whereas
> >> the lockless model rolls out there pretty easily, especially if you
> >> allow objects to migrate between DB servers.
> 
> >My method would support RPC model of distribution, with remote
> >proxies...
> 
> This sounds a lot like Cool's model.

Exactly. Cold model, unlike Cool's, combines core with driver support
(it uses extended frobs for proxies, and method calls on those objects
get redirected to the core object that does the marshalling and sends
the call to the remote).

> Unter originally took the replication model.  Latter design
> discussions that I've heard of spoke of doing RPC until a threshhold
> value (balance of local calls to remote calls from specific target) at
> which point the object would be moved to the preferential server.

I like this, but i'd have to do some thinking to figure how to do it
(well, of course, I'll not be the only one to do the thinking).

	Miro