Editing Atomicity (database systems) (section)

==Implementation==
Typically, systems implement Atomicity by providing some mechanism to indicate which transactions have started and which finished; or by keeping a copy of the data before any changes occurred ([[read-copy-update]]).  Several filesystems have developed methods for avoiding the need to keep multiple copies of data, using journaling (see [[journaling file system]]). Databases usually implement this using some form of logging/journaling to track changes. The system synchronizes the logs (often the [[metadata]]) as necessary after changes have successfully taken place. Afterwards, crash recovery ignores incomplete entries. Although implementations vary depending on factors such as concurrency issues, the principle of atomicity – i.e. complete success or complete failure – remain.

Ultimately, any application-level implementation relies on [[operating system|operating-system]] functionality.  At the file-system level, [[POSIX]]-compliant systems provide [[system call]]s such as <code>open(2)</code> and <code>flock(2)</code> that allow applications to atomically open or lock a file. At the process level, [[POSIX Threads]] provide adequate synchronization primitives.

The hardware level requires [[linearizability|atomic operations]] such as [[Test-and-set]], [[Fetch-and-add]], [[Compare-and-swap]], or [[Load-Link/Store-Conditional]], together with [[memory barrier]]s. Portable operating systems cannot simply block interrupts to implement synchronization, since hardware that lacks concurrent execution such as [[hyper-threading]] or [[multi-processing]] is now extremely rare.{{Citation needed|date=December 2016}}