[MUD-Dev] Re: atomic functions

J C Lawrence claw at under.engr.sgi.com
Wed May 6 11:44:18 New Zealand Standard Time 1998


On Sat, 2 May 1998 03:41:43 -5 
Jon A Lambert<jlsysinc at ix.netcom.com> wrote:

> On 30 Apr 98 at 3:59, Felix A. Croes wrote:

> Very interesting.  J.C. has been quite convincing and has opened my
> eyes to many good ideas in this area.  

<slick>  <click>  <click>

<<damn nerf gun is outta bullets>>

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

...deletia...

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

Problem:

  Foo() executes, and launches bar() as a seperate execution thread.

  Foo() then fails C&C (S&S?).

  What happens to the launched bar()?

  Foo() reschedules, does it launch a new bar()?

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

...deletia...

> Whilst mine is:

...deletia...

> No? More comments?

At some point data changes have to be commited.  Given the rollback
and reschedule aspect of the C&C approach, on what logical basis can
you have nested commit structures or event fork()s _prior_ to commit?

Now if you mutate the C&C premise in some interesting fashion, (you
never did really explain the basics of S&S), you can certainly do it
-- but now you are talking about a whole different commit model.
Essentially we are talking about the sematics and grammar of data
state changes, and that grammar has to be logicially demonstrable.

--
J C Lawrence                               Internet: claw at null.net
(Contractor)                               Internet: coder at ibm.net
---------(*)                     Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...

--
MUD-Dev: Advancing an unrealised future.



More information about the MUD-Dev mailing list