atomic
Here’s an example:
A wants to transfer ￥1000 from its own account to B’s account. The process of transferring money from A to the end of the transfer is called A transaction (A set of operations performed on the system to accomplish some purpose). In this transaction, do the following:
- Subtract ￥1000 from A’s account. A used to have 2000, but now it becomes 1000.
- Add 1000 to B’s account. B used to have 3000, but now it has 4000.
If after the completion of the first step, an accident suddenly occurs, resulting in the unexpected termination of the transfer transaction, at this time, the account of A has decreased by 1000, while the account of B has not increased by 1000. If the operation fails, A rollback is required (rollback is to return to the state before the transaction started: A:2000 B:3000).
This property that the set of operations that complete a transaction either all execute the commit together or fail together (rollback to the original state) is called atomicity of a transaction. Therefore, to say that a transaction is atomic means that it is a complete operation that cannot be interrupted during execution (for example, in multithreaded operations, when the thread is suspended while waiting for a resource, the recording context cannot be executed next time).
In the database, the transaction refers to the operation process of data in the database, and in the program, the transaction refers to the operation process of data in memory.
To sum up, the definition of atomic operation can be obtained:
Atomic operation
Operations that are not interrupted by thread scheduling. Once the operation starts, it runs all the way to the end without any context switch.
An atomic operation can be a single step or multiple steps, but the sequence cannot be disrupted, nor can it be cut to perform only some of them. Seeing the whole operation as an indivisible whole is a central feature of atomicity.
For example, in Java, assigning to underlying data types that are not long and double: int a = 25;
How to realize the atomicity of operation
Related articles: blog.csdn.net/xuxile/arti…
Atomicity of properties in iOS
When declaring a property, set the atomic and nonatomic properties of the property.
Atomic: The getter/setter method of a property is an atomic operation. If multiple threads call the setter at the same time, it is not possible for another thread to execute the setter before completing all of the statements in the setter. This means that the system locks the function, which results in low performance and resource consumption when accessing concurrently.
Nonatomic: Generally used when you do not need multiple threads to access properties, more efficient. OC properties are usually set to non-atomic because a single thread is automatically generated when an iOS program is started, and properties are typically operated on by a single thread during program execution.
When we determine in the program that a certain attribute will be used in multithreading and need to do data synchronization, we must set it to atomic, but we can also set it to non-atomic, and then use locking and so on in the program to do data synchronization.
Atomic operations are thread-safe in multithreading, with no synchronization concerns.