[MUD-Dev] Atomic Functions

[Ben]

Par Winzell writes:
> 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.

Are you saying that this basically does away with the need to lock your
threads so that
they don't cause errors?  And also, how would you apply this to ALL
functions in your
code, would you have to write the code for each function to be atomic, or
just a general
that then has sub functions or something?


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