The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (McKown, John) writes: > "Atomic" is used quite a bit in computer science. Like the original > Greek, it means "indivisible". That is, when an atomic operation occurs, > any other process will either see the data in the original form, or in > the updated form. But it will never seen an intermediate form. It is > especially used in relational databases. This is usually done so that, > for instance, if you transfer money from checking to savings, you never > see the amount in both places. You either see the amount in checking or > in savings. This despite the fact that a lot of stuff is going on to do > the move. > > "compare and swap" simply means that. It compares field1 against field2. > If field1 equals field2, then the contents of field3 is placed in > field2. What is "atomic" is that there is a "lock" that occurs so that > at the instant before field1 is compared against field2, no other > process is allowed to modify or even look at field2 until after the > instruction finishes. This ensures that once the operation starts that > no other process can make any updates or decisions based on the contents > of field2. there are ACID properties with regard to transactions ... frequently things like financial. A .. atomicity C .. consistency I .. isolation D .. durability a wiki ref http://en.wikipedia.org/wiki/ACID simpler example is two concurrent transactions, one a debit and one a credit ... attempting to update the *same* value. say you have $5000 in savings account. there is a transaction that fetches the current value ... in order to subtract a $200 ATM debit. At the same time there is another transaction that is attempting to perform (add) an EFT $1000 deposit. W/o the transaction serialization semantics, the EFT $1000 deposit concurrently fetches the current ($5000) value, adds $1000 and starts a store operation of the $6000 value ... concurrently while the ATM debit is performing the store of the $4800 value. correct transaction atomic serialization, should result in correct $5800 when everything is done. w/o transaction atomic serialization, the $6000 "store" might be done followed by the $4800 "store" ... or the "4800" store might be done followed by the $6000 "store" (resulting in either $4800 or $6000, neither correct) for the compare&swap scenario. The $4800 "store" only completes if the value being replaced is $5000 ... otherwise things start all over ... similarly, the $6000 "store" only completes if the value being replaced is $5000 ... otherwise things starts all over again. in transaction systems, this is sometimes referred to as "optimistic" ... as opposed to purely serialized locking systems ... which only allow one single transaction at a time to fetch a value ... and no other transaction is allowed to fetch a value (or otherwise proceed) until the active transaction has completed ... this is somewhat analogous to the kernel spin-lock mentioned in previous description: http://www.garlic.com/~lynn/2008b.html#58 How does ATTACH pass address of ECB to child? the transaction properties for consistently updating two different values ... is somewhat more complicated ... than simple compare&swap. Doing a transfer from one account to another requires that two values (not just one) be correctly updated as a single, syncronized, serialized operation (w/o allowing other simultaneous transactions to corrupt the values). in a few, carefully controlled situation it can be done by compare-double & swap. a savings account value and the debit account value are stored in contiguous storage locations. For a "transfer" operation, both values are fetched, and the appropriate changes (a subtraction from one and an addition to the other) are made to both values. then compare-double and swap is executed ... only succeeding with the replace of both values IFF (if & only if) neither value has changed since the original fetch operation. If either or both values have changed since the initial fetch (because other operations are concurrently attempting to change the same fields) ... then the store operations fail ... and the process starts all over again. the other alternative ... for concurrent updates of multiple different values is to resort to something like the spin-lock scenario ... only allowing one processing to performing operations at a single time. As pointed out ... to avoid getting into trouble ... the active running transaction can't be interrupted while it is performing the "locked" operation. compare&swap semantics tends to provide much higher level of concurrent operations with much lower overhead for providing correct serialized operation. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
