1

I'm reading some papers on distributed systems. The authors claim to be able to have a sequence of operations executed atomically (either all operations are executed successfully or none is executed, even when system failures occurs). I wonder how it is achieved. Thanks in advance!

Burgess Chen
  • 21
  • 2
  • 2
    As seen by the difference in my answer and madscientist159's answer, this is a pretty broad question. Are you looking specifically at atomicity in distributed systems, or just atomicity in general? – deckeresq Aug 01 '17 at 04:02
  • Would you mind to at least cite the source paper, so as to bring in the full context of your question? – user3666197 Aug 01 '17 at 15:27

3 Answers3

0

This is done all the time, though the key (and possibly the confusion here) is that the instructions are partially executed at time of interruption, but the original state of the data is still known and can be automatically reverted to on detection of the system failure. For very well known examples, simply look into databases and journaling file systems.

In a nutshell, one would make sure that all operations are stored in a temporary buffer that can be merged into permanent storage in a truly atomic fashion. As an example, one could atomically edit a file using a temporary buffer to store changes, and then use an atomic move at the filesystem level to commit those changes to the original file. If the editing process is interrupted, the original file remains untouched.

Once the basic concepts involved are understood, the rest becomes simple implementation as you move down the hierarchy toward the hardware itself. Modern CPUs offer specific instructions that guarantee atomicity at the hardware level itself; these are used to "bootstrap" atomicity at higher levels through mechanisms such as semaphores and journalling.

madscientist159
  • 550
  • 4
  • 12
  • With all due respect, **do you have any recognised Computer Science paper citations support for the proposed swap of terms** once -- pointing to just a **transaction** { commit | rollback } terminal state **consistency** concept, instead of the **atomicity of execution**, which was the O/P subject matter? Thank you for pointing us to relevant sources. – user3666197 Aug 01 '17 at 15:22
  • The OP was somewhat unclear on what they were specifically looking for. I made the (not unreasonable) assumption that final data state was important as any system will need to execute the instructions partially even in the case of failure (as a prerequisite to even being able to *have* a failure in the middle of processing). If the OP clarifies this was not what was being sought after I will delete the answer. – madscientist159 Aug 02 '17 at 21:32
  • There is also another flavour of atomicity -- i.e. a mechanism for a guarranteed mutual non-intervening -- that any and all computations do reflect a state "before" in the very same manner + they do not not intervene ( modify ) any variable / state "during" their co-processing, irrespective of ordering / scheduling constraints. That is the harder part. – user3666197 Aug 02 '17 at 21:48
0

It is possible to have a block of code executed atomically, absolutely.

Try checking out the semaphore, which is often considered the "building block" of atomicity. Essentially, when code attempts to run, it tries to grab a virtual flag. If it is unable to do so, it waits (or does nothing, depending on the implementation). So, an extremely naive implementation looks something like this (assume that there may be any number of A's or B's running at any given time):

int semaphore = 1;

void processA() {
  while (semaphore <= 0)
    ;
  semaphore--;

  //do something atomically

  semaphore++;
}

void processB() {
  while (semaphore <= 0)
    ;

  semaphore--;

  //do something atomically

  semaphore++;
}

As I mentioned, this is an extremely naive implementation -- see if you can see where what's depicted here might fail. Hint: Consider how many steps each operation ACTUALLY takes. For example, A = B + C is actually 4 steps: read B, read C, add B and C, store in A.

deckeresq
  • 332
  • 2
  • 14
0

A Principal Solution:

Without waiting for any wider context, my implementation bet would go straight to use of FPGA-s inside a principally ( M + N )-fail-safe infrastructure, thus systematically avoiding any single-point-of-failure within the fault-tolerant system perimeter.

Code-block wide atomicity could hardly be implemented, as far as my experience could be harnessed, in any cheaper manner than using such architecture approach.

user3666197
  • 1
  • 6
  • 50
  • 92