[MUD-Dev] Re: atomic functions

[Jon A. Lambert]

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.

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

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

 
--
--/*\ 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.