An atomic operation is indivisible. This term is used to describe transactions in databases, low-level accesses in multithreaded programs, and file system operations, amongst others.
An operation is atomic if it is indivisible --- either all the effects of the operation are visible, or none are.
In databases, the atomicity of transactions is one of the basic guarantees --- it is the A in ACID. This allows you to ensure that the data changes from one consistent state to another, even when updates cover more than one table.
In multithreaded programs, atomicity is important for building low-level facilities, as it ensures that code running on other threads either see the value before a change or the value after, and not some intermediate value. Locks are implemented terms of atomic operations, but they can also be used directly to create lock-free algorithms.
Atomicity is a property of a single memory operation (a store, a load, or a read-modify-write). In assembly language, aligned loads and stores are usually atomic by default (like on x86), but a read-modify-write like num++
isn't.
Transactional memory systems allow changes to multiple variables to be done as a single atomic operation, akin to database transactions.
In high-level languages, where the compiler takes care of keeping variables in registers or memory, it's not always safe to assume anything about when/if stores/loads actually happen. Some languages provide types where all operations are atomic (for example C11's and C++11's stdatomic).