Multithreading Security implications

This article highlights

• Multithreading Security hidden Danger leads
• Multithreaded security Vulnerability code example
• Multi-threaded security hidden trouble solution

One, multi-thread security hidden danger leads

Suppose the train station has 3 ticket sales window, the remaining ticket is 1000, the ticket window 3 threads at the same time to read the remaining votes, are read 1000, sell the ticket thread 1 sold a sheet, the remaining votes into 999. The ticket thread 2 responds slowly and executes the sell ticket after the ticket thread 1, because the ticket thread 2 has just begun to read the remainder of the ticket is also 1000, so after selling a sheet, the balance becomes 999. The ticket thread 3 reacts more slowly, after the ticket thread 2 executes the sell ticket, because the ticket thread 3 has just started to read the remaining ticket is also 1000, so after selling one, the balance still becomes 999. So there was a mistake, originally sold 3, but more than 999 tickets.

Therefore, when multiple threads access the same piece of resources (the same object, the same variable, the same file), it can easily cause data confusion and data security problems.

Two, multithreading security hidden Trouble code example

1> declares 3 ticket-selling threads, as well as leftticketcount to save the remainder of the ticket

@property (nonatomic, strong) Nsthread *thread1; Thread 1 @property (nonatomic, strong) Nsthread *thread2; Thread 2@property (nonatomic, strong) Nsthread *thread3; Thread 3 @property (nonatomic, assign) int leftticketcount; Number of votes left

2> in Viewdidload, set the remaining ticket to 50 tickets, and created 3 threads, and respectively named "Window 1th", "Window 2nd" and "3rd window"

Self.leftticketcount = 50;self.thread1 = [[Nsthread alloc] initwithtarget:self selector: @selector (saleticket) object: Nil];self.thread1.name = @ "Window No. 1th";
Self.thread2 = [[Nsthread alloc] initwithtarget:self selector: @selector (saleticket) object:nil];self.thread2.name = @ " Window No. 2nd ";

Self.thread3.name = @ "Window No. 3rd";

3> realization of Ticketing method

}

The output is:

It can be easily seen from the results that multiple threads access and manipulate the remaining number of votes, causing data confusion and data security issues

Three, multi-threaded security hidden trouble solution

After thread a reads the data, a lock is added, and the other threads are inaccessible, allowing only the locked thread A to access. When the lock thread finishes manipulating the data, thread a unlocks, at which point the other threads can access it, assuming that the thread B accesses it, thread B also locks the lock to ensure that only its own access is available, and then unlocks it after the operation is done .... In this way, as long as the person who accesses the lock, until the end of the operation and then unlock. This is the mutex.

The purpose of locking is to ensure that only one thread accesses and executes the code at the same time.

Code implementation Mutex Lock

-(void) Saleticket {while    (1) {        ///()? parentheses? The Lock object         @synchronized (self) {//Start lock    



}}        

By locking itself as a lock object, to ensure that they access the operation data, other threads can not come in, only wait for the execution after the lock.

Attention:

1. The @synchronized (self) cannot be written in front of while (1), although the result is correct, but always executes only the first incoming process.
2. Although mutexes can effectively prevent data security problems caused by multi-threaded looting of resources, they need to consume a lot of CPU resources.
3. And only use mutexes when more threads rob the same resource

Multithreading Security implications