IOS-Mutex && spin lock multithreading Security Risks (reprint)

One, multi-threaded security risks

resource Sharing
A resource may be shared by multiple threads, that is, multiple threads may access a resource
For example, multiple threads access the same object, the same variable, and the same file.
When multithreaded access to the same piece of resources, it is easy to trigger data confusion and data security problems
Second, atomic and non-atomic properties
1>oc There are two options for nonatomic and atomic when defining attributes
*Atomic: Atomic attributes, locking for setter methods
*nonatomic: Non-atomic attribute, does not lock the setter method
The general situation is in the main thread to do the operation, so generally do not lock.
Contrast:
* Atomic: Thread-safe, requires a lot of resources
* Nonatomic: Non-thread-safe, suitable for small memory mobile devices
2>synchronized and Atomic
*synchronized: Mutual exclusion Lock
*Atomic: Spin Lock
Common Ground: Ensures that only one thread can operate the locked code at the same time
difference：
Mutual exclusion Lock: When the task of the previous thread is not completed (locked), then the next thread will go to sleep waiting for the task to complete, and the next thread will be when the task of the previous thread finishes executing. Automatically wakes up and executes the task.
Spin lock: When the task of the previous thread is not completed (locked), the next thread waits (does not sleep), and the next thread executes immediately when the task of the previous thread finishes.
Spin Lock Application Scenario: It is more suitable to do some time-consuming operation
Third, mutual exclusion lock
· Note the point:
-If you have multiple threads accessing the same resource, you must use the same lock to lock
-In the development, try not to lock, in the service to do as far as possible in the service side, if you have to lock, it must be remembered that the scope of the lock can not be too large, where there is a security hidden danger on the Add.
Tip: Because you must use the same lock, you can use self directly if you need to lock it in development.

@synchronized (self) {///thread 1 comes in, lock, 2 and 3 wait outside//1, query the remaining number of votes nsuinteger count = SELF.TOTALCOUNT;//2, judge whether there is still a ticket//2.1 sell tickets//3, Prompt customer, no ticket out if (count>0) {[Nsthread sleepfortimeinterval:0.1];self.totalcount = count-1; NSLog (@ "%@ sold a ticket,%zd tickets left", [Nsthread currentthread].name,self.totalcount);} else{NSLog (@ "no ticket"); break;}} Unlock

Four, Spin lock
Note the point:
Only locks the setter method and does not lock the Getter method.

IOS-Mutex && spin lock multithreading Security Implications (reprint)