[MUD-Dev] Atomic functions

[Par Winzell]

KevinL writes:
 > I had the whole thing explained to me by better minds than mine -
 > the atomic functions are a way to try and do a bunch of things at
 > once, and instead of suffering the overhead of checking everything
 > first, you can just "raise an exception" (in essence), and let the
 > machinery put things back as they were (in fact, things never change
 > until the atomic function completes successfully).  It's not a
 > multi-thread apparatus, which is what confused me,
 >  
 > It's more of a performance tweak and ease-of-coding tweak.  Is that
 > closer to the truth?  It's not going to catch situations where
 > someone else changes things while you're running, because it's not
 > designed to - it's simply designed to stop you from having to
 > explicitly deal with failures by winding back changes yourself all
 > the time.

As I see it, it is indeed an ease-of-coding tweak, but one that ends
up changing the way you approach your code fairly dramatically. It's
true that for simple functions, the traditional approach works well:
first do all the sanity checks, then modify the data structures.

Even for these simpler functions, though, the feeling of freedom is
almost exhilirating; suddenly you can throw years of sanity-checking
discipline to the winds and just write your manipulations in the most
aesthetically pleasing manner.

For me, the most liberating advantage of atomic functions lies in the
truly complex operations, the ones involving calls through many layers
of abstraction, the ones that can take seconds of machine time to run.

As an example, one of the most common things for a Skotos development
server to be doing is to accept a HTTP post of the XML definition of 
some in-game object that somebody was just editing in their browser.

Once the XML is parsed, the target object is essentially erased, then
completely rebuilt with the new data. This involves hundreds of calls
to set_this() and set_that() functions in the object, all of which do
their own error-provoking sanity checks. If 80% of the way through the
object an error is encountered -- perhaps the developer referenced an
object that no longer exists -- then the entire reconstruction of the
object is rolled back and you are -guaranteed- that things are as if
the post never occured.

Anybody who's done work carefully modifying complex tables in an SQL
database can imagine how much fun that would be without commits and
rollbacks. Atomic functions are a -really- good idea.

Zell




_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev