For iOS development of the network request module, the use of AFNetworking should be the most familiar, but do you grasp the right time to complete the network request? What is semaphore?
1 what is the semaphore.
Signal: is a can be used to control the number of access to the resources in the logo, set a signal, in the thread before the trip, plus the amount of signal processing, can inform the system according to the number of signals we specify to execute multiple threads. In fact, it is a bit like a lock mechanism, but the signal is helping us to deal with, we only need to perform before the thread, setting a signal value, and when in use, and the signal processing method on the line.
Semaphore has 3 functions, namely:
Create a semaphore signal parameters: initial
Dispatch_semaphore_create (signal value)
Wait for the lower signal (signal dispatch_semaphore_wait, waiting time)
To improve the signal dispatch_semaphore_signal (signal)
2 in real development, we usually encounter the following problems:
There are multiple requests for an interface, and it is hoped that all requests will be completed before the following operations are performed.
The solution is easy to think through the thread group. The code is as follows:
The results are as follows:
printing results may not be a problem, but it should be noted that the request1 request2 request3 in the real development is usually a corresponding network request. The network requests are usually asynchronous, then there will be the same results?
Let’s look at the request of the network.
For App request data most people will choose AFNetworking. Using the AFN asynchronous request, the requested data is returned, the refresh related UI. If a page has multiple network requests, we assume that there are three requests, request1, request2, request3, and UI data in request1, request2, request3 have to wait until after the completion of all refresh after the show.
Here we write a general method for network requests. Using our most common AFNet request, the following:
request2 request3 request corresponding to the following data, it will not repeat the writing, the end of the article will be attached to the demo address, interested can download to see.
The results are as follows:
operation immediately after receiving thread group completed after the data suggest that only turn down requests, obviously three simple AFNetworking requests have been unable to meet our demand. The thread group is not notified when we want it to be done. In the real development of the problem will be caused by multiple requests are loaded, but the interface has been in front of the data did not get ahead of the interface refresh.
Here we will use the GCD signal dispatch_semaphore to achieve, that is to create a thread synchronization.
A multi thread synchronization mechanism based on counter for dispatch_semaphore signal. Used to solve the problem of multiple threads to access the shared resources, because of the characteristics of multi thread and cause data errors.
If the semaphore count is greater than or equal to 1, count -1, return, the program continues to run. If the count is 0, wait.
Dispatch_semaphore_signal (semaphore) for count +1 operation. Dispatch_semaphore_wait (semaphore, DISPATCH_TIME_FOREVER) for setting the waiting time, waiting time set here is always waiting.
Modify the network request as follows:
solves this problem perfectly by the amount of dispatch_semaphore, and the network requests are still asynchronous and will not block the current main thread.
Example address: Click to download