[MUD-Dev] Re: atomic functions
Felix A. Croes
felix at xs1.simplex.nl
Sun May 3 01:23:43 New Zealand Standard Time 1998
Jon A. Lambert <jlsysinc at ix.netcom.com> wrote:
> On 1 May 98 at 13:26, Shawn Halpenny wrote:
> > So atomic fragments are akin to critical sections? For me, methods can
> > execute in their own context (essentially the call stack of an event's
> > processing is an entire critical section). Since they receive current
> > copies of any data they touch, rather than having to wait for it to
> > become available, though, there's no waiting upon entry. Given the way
> > I've structured things, atomic fragments don't add much benefit (but see
> > below).
> There are a couple of issues here, asynchronous event execution and
> data currency/integrity. In looking at his model, it appears to be an
> example of how data currency/integrity issues would be handled at the MPL
> (or LPC) level. I'm not sure yet how his events are generated.
My server is a rewrite from scratch of LPmud, so events can be
generated in two different ways: a status change for a socket
(connection available/input available/output done/connection lost)
or with the infamous "call_out" function. I would like to rename
the latter to something that makes more sense, but at this point
I am bound to backward compatibility.
I mean to have both asynchronous event execution and data
currency/integrity. The interesting part is that the same
code can be used for both.
> > Explicitly defining an atomic function would require more programmer
> > work. In a free user programming environment, I don't want to require
> > people to decide whether the function they just wrote to make their
> > sword talk needs to be atomic or have atomic sections within it. For
> > now, I'm opting to leave it up to the server to decide the atomicity of
> > things (which it does by way of the event and DB models). An
> > experienced programmer can probably outdo the server if given the
> > capability to declare atomic blocks, but a newbie would be more
> > inclined to either not declare them at all (in which case, I'd have to
> > rely on a system like I've already got in mind) or declare them poorly
> > and result in performance worse than the server would obtain doing it
> > itself.
> Exactly so. Providing for explicit data currency in the language makes
> it a much more powerful tool, although there is the side-effect that
> programming for data currency is more complex.
> I've taken a similar position to yours, where data currency is implicitly
> linked to event atomicity (is that a word?).
> My event method call() is
> the explicit way of declaring that data currency is NOT important or
> non-critical. Perhaps the semantic opposite of Felix's model?
I don't understand this.
> Thus an Event may be made up of many methods/functions, all of which must
> succeed for the event to commit. Methods may schedule additional Events
> and these events will be scheduled regardless of whether the generating
> Event succeeds or not. So in many cases, Event calls will be obviously
> be placed just before the successful return of the top-most method.
> There is a caveat. A method/function which is called as an event
> should ensure that it checks the state of the caller/callee for state
> validity. Nothing comes for free. I have just shuffled the complexity
> into another area of program design. I have a theory this might be
> unavoidable. :(
Hmm. That is one thing I mean to do differently: if the current
event fails to commit, then any events generated by it are unscheduled.
MUD-Dev: Advancing an unrealised future.
More information about the MUD-Dev