[MUD-Dev] Re: atomic functions

[Felix A. Croes]

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?).

Atomicity?  Atomicness?


> 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.

Felix

--
MUD-Dev: Advancing an unrealised future.