[MUD-Dev] Re: atomic functions

[Jon A. Lambert]

On  3 May 98 at 1:23, Felix A. Croes wrote:
> Jon A. Lambert <jlsysinc at ix.netcom.com> wrote:

I've combined both messages into one reply.

> 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'm not familiar with LPC, but my 'event method()' seems to be similar to 
the LPC 'call_out()' function.  Hrrm, so it's infamous is it?  
 
> 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.

Yes.  Exactly.  Events that are asychronous have that property because 
they have no data currency issues with each other.

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

The backward compatibility issue with LPC makes explicit declaration
of atomic functions or code sections more critical to you.  For me any 
method entered via an event is implicitly atomic.  And I must make calls 
to execute methods that are no longer dependent on the currently 
executing event's success explicit.  

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

Currently I have no way to do this.  

> Note that I mean to have atomic sections <in addition to> multithreading
> with commits and rollbacks (even though I may not implement them as
> rollbacks).
> 
> Shawn has made me realize that there are two kinds of "atomicness".
> First, every (completed and committed) event can be said to be atomic in
> the sense that it does not overlap with other (completed and committed)
> events.
> 
> Second, a section of code can be said to be atomic if it is executed
> either entirely or not at all.  In my system, the two kinds are
> distinct.  In Shawn's, they are identical.  In a system that is
> multithreading in the same way but in which a runtime error does not
> cause the event to fail, only the first kind exists.

In my system only the first sort would exist.  My events are 
transactions.  Either they are successful and commit or they fail and
rollback.  Events execution order is unpredictable.  They only way to 
spawn new events within the mud language is by using the "event 
method()", while a normal "method()" call does not.  The driver will 
of course generate events of it's own like data arriving on a 
connection, startup, shutdown, sync points, and likely others I haven't
thought up yet.
 
For another take on atomic() see Cold's implementation at:  
        <http://ice.cold.org/bin/help?node=$help_func_atomic>

--
--/*\ Jon A. Lambert - TychoMUD     Internet:jlsysinc at ix.netcom.com /*\--
--/*\ Mud Server Developer's Page <http://www.netcom.com/~jlsysinc> /*\--
--/*\   "Everything that deceives may be said to enchant" - Plato   /*\--

--
MUD-Dev: Advancing an unrealised future.