[MUD-Dev] Re: lockless system - foolproof?

[James Wilson]

On Mon, 31 Aug 1998, J C Lawrence wrote:
>On Sun, 30 Aug 1998 20:36:11 -0400 
>James Wilson<jwilson at rochester.rr.com> wrote:
>> On Sun, 30 Aug 1998, J C Lawrence wrote:
>>> On Sat, 29 Aug 1998 19:42:17 -0400 James
>>> Wilson<jwilson at rochester.rr.com> wrote:
>
>>> The easiest and perhaps the simplest way of attacking this is thru
>>> approaching the level of parallelism in your execution model.
>>> Again, taking the pessimal case, if the execution model degrades
>>> until only one event is executing at a time, then X is guaranteed
>>> to successfully C&C when its turn comes as there is no competition.
>>> 
>>> This is the approach I take.  Events enter the Executor with a
>>> "priority" value.  As events fail C&C they accumulate priority.
>>> The executor's execution model then adapts dynamically per the
>>> highest priority event on its list.  At one end its the normal
>>> unrestrained competition between events, and t the other it
>>> degrades to single-tasking with everal stages in between.

[snip]

>> You mentioned that you are designing with user scripting in mind. If
>> one of those contentious events ends up getting a monopoly on cpu
>> time, *and* it's of long/indefinite duration (which would seem to
>> correlate nicely with the propensity for contentiousness),
>> everything would freeze waiting for it.
>
>Pessimally, nearly yes.  In practice no.  The game-wide event thru-put
>will (fairly rapidly) degrade to single-tasking, and then resume
>immediately with normal processing.  Should the offensive event be a
>raid respawner (ie there are many such events and/or each one creates
>further like itself) which is the ultimately pessimal case, the game
>will enter a yo-yo-like state of constantly entering single-tasking
>mode and then leaving it.
>
>However such excessively contentious events are easy to detect and
>guard against.  Here, I (used to) run a little statistics monitor that
>would note any events that took the game to or near single tasking
>mode, and if the repeated more than once an hour, would spoof the
>defining object and freeze the event calls for admin intervention.

so you've essentially disallowed these contentious-by-nature events, right?

>> While some might say it seems a bad idea to allow users to write
>> long-running functions, a scripting system would seem to me to be
>> most useful to builders wanting to add new functionality to the
>> world without having to muck about in the source code. 

[snip]

>That said, much like the old argument of C vs Pascal, free scripting
>on MUDs is akin to handing chainguns with hari triggers to monkeys.

heh.

Seriously, I am reconsidering my own attachment to user scripting, in
light of this whole threading issue.

>> In this case, putting bounds on running time would be a serious
>> constraint on builder creativity. Ideally, bounding runtimes should
>> be a matter of policy rather than forced by the implementation.
>
>Disagreed, strongly.  The reason is actually simple: I find that
>extremely long running or contentious events are actually of flawed
>base design.  There is always another divisional structure that allows
>the same result to be accomplished with less contention points, and
>often with far greater elegance.

[example snipped]

I guess there's two issues here. First, is everything that is possible
with contentious events possible with equivalent non-contentious events? 
I would think not, but perhaps enough functionality would remain to still
make the system practical. I'm no computer scientist, so I'll leave 
the formal proofs to someone else. ;) Second, what degree of skill would 
users need to have to properly script non-contentious events?

[snip]

>This is the sort of things which I am unwilling to proof against.  I'm
>willing to make the system withstand such onslaughts (monolithinc long
>running events), which it currently does, but I am not willing to
>require the system to perform well under such (it doesn't).

Agreed. As long as a system is powerful enough, it will be vulnerable in 
some sense (if only to resource attacks). I don't think there's a way
around this, just different sets of tradeoffs.

James