[MUD-Dev] Re: atomic functions

[Felix A. Croes]

Jon A. Lambert <jlsysinc at ix.netcom.com> wrote:

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

"Event function"?  I had not thought of a name for it yet, but definitely
not atomic fragment.


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

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.

What made me confuse the two kinds of "atomicness" is that they
can be implemented with almost exactly the same code.

Felix Croes

--
MUD-Dev: Advancing an unrealised future.