Atomic transaction
|
|
In computing, an atomic transaction is a database transaction or a hardware transaction which either completely occurs, or completely fails to occur. A prosaic example is pregnancy - you can't be "halfway pregnant"; you either are or you aren't.
For example, when transferring an amount from bank account A to account B, if the machine loses power, it is best that neither account's balance be changed, so typically an atomic transaction would be used. As another example, the vipw program on some Unix-like operating systems uses a lock file to force atomic editing of the password file by one user at a time, as well as providing other guarantees about the state of the file.
Atomicity is an important component in avoiding race hazards. An atomic operation is guaranteed to have either of two known outcomes (i.e. complete success or complete failure) and when multiple processes attempt to perform an atomic operation, it is guaranteed that only one will succeed (however either or both may fail!)
Typically, atomicity is implemented by providing some mechanism to indicate which transactions have been started and finished, or by keeping a copy of the data before any changes were made. Several filesystems have developed methods for avoiding the need to keep multiple copy of data, using journaling (see journaling file system). Many databases also support a commit-rollback mechanism aiding in the implementation of atomic transactions. These are usually also implemented using some form of logging/journaling to be able to track changes. These logs (often the metadata) are synchronized as necessary once the actual changes were successfully made. Unrecorded entries are simply ignored afterwards on crash recovery. Although implementations vary depending on factors such as concurrency issues, the principle of atomicity, complete success or complete failure, remain.
Ultimately, any application-level implementation relies on operating system functionality which in turn makes use of specialized hardware to guarantee that an operation is non-interruptible by either software attempting to re-divert system resources (see pre-emptive multitasking) or resource unavailability (e.g. power outages). For example, POSIX-compliant systems provide the open(2) system call which allows applications to atomically open a file. Other popular system calls that may assist to achieve atomic operations from userspace consist of mkdir(2), flock(2), fcntl(2), rasctl(2) (NetBSD restartable sequences), semop(2), sem_wait(2), sem_post(2), fdatasync(2), fsync(2) and rename(2).
At the hardware level, instructions such as test-and-set (TAS), and/or atomic increment/decrement operations are needed. When these are lacking, or when necessary, raising the interrupt level to disable all possible interrupts (of hardware and software origin) may be used to implement the atomic synchronization function primitives. These low-level operations are often implemented in machine language or assembly language.
The etymology of the phrase originates in the Classical Greek concept of a fundamental and indivisible component; see atom.