[MUD-Dev] Re: atomic functions

[Jon A. Lambert]

On 30 Apr 98 at 3:59, Felix A. Croes wrote:
>
> Having recently completed the implementation of the generic parsing
> utility that I posted about earlier, I am now preparing to convert
> my server to the lockless multithreading paradigm put forward on this
> list by J.C. Lawrence.
>
> It has occurred to me that the commit-or-fail idea can be applied to
> parts of threads as well as entire threads, leading to the following
> concept of "atomic functions":
> 
>     An atomic function is a function that succeeds or fails as a
>     whole.  Any runtime error that is not caught within the function
>     will lead to the entire function call, with all its effects
>     and side-effects, being undone.
> 
> Atomic functions would be used to enforce consistency -- just like a
> thread either fails or succeeds without leaving the mud in an
> inconsistent, half-completed state.  Of course, every function called
> at the beginning of a thread is effectively called atomically, so
> code that depends on atomic functions can be replaced by code that
> depends on (atomic) threads.  The advantage of atomic functions
> would be to place the function call within the wider thread
> context, which would be similar to imposing an execution order on
> threads.  Also, calls to atomic functions could be nested.
> 
> Comments?  Is anyone already using this for his own server?
> 

Very interesting.  J.C. has been quite convincing and has opened my 
eyes to many good ideas in this area.  I'm adopting something I've 
dubbed S&S or Spin-Lock and Swizzle.  In essence a multithreaded 
locking system.  But ignoring this implementation detail, the 
language implementation is more relevant here. 

My terminology differs with yours slightly: 

   Transaction == Event == Atomic function 
        ... and is assumed to be == Thread   
   Method call == Function call
   Event Method() ~?~ Atomic {fragment} --> not sure here

And from the posted examples of pseudocode we have: 

Felix:
 foo()
 {
     /* code fragment 1 */

     atomic {
  /* code fragment 2, executed atomically */
     }

     /* code fragment 3 */
 }

Jon:
 foo()
 {
     /* code fragment 1 */
     event bar();  /* bar is sceduled for execution as an atomic 
                      function or independent event.  Execution
                      foo() is not suspended but continues 
                    */
     bar(); /* executes bar() as a normal function bar is part of foo */  
        /* code fragment 3 */
 }
 bar()  
 {
     /* code fragment 3 */
 }

Either foo() or bar() may be events or normal functions. Whether they are 
atomic events scheduled for independent execution is dependent on how 
they are called.  Commits are done on successful event completion.  
Rollbacks are done on event failure. 

I think the difference may lie in that your atomic is
more like:

 foo()
 {
     /* code fragment 1 */
     BEGIN_TRANSACTION{
     /* code fragment 2, executed atomically */
     }
     COMMIT_TRANSACTION
     /* code fragment 3 */
 }

Whilst mine is:

 foo()
 {
     /* code fragment 1 */
     FORK bar()
     /* code fragment 3 */
 }

No? More comments? 

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