Note: Calls to signal() must be balanced with calls to wait(), otherwise an EXC_BAD_INSTRUCTION exception will be raised. Its API is tiny with one initializer init(value:) and two primary methods signal() and wait(). In Grand Central Dispatch (GCD), semaphore is an instance of DispatchSemaphore. The former can be used to implement a lock since its value is either 0 or 1 representing unlocked or locked state, while the latter allows a resource count which indicates the availability of the resource. There’re two types of semaphore, binary and counting semaphore. The resource may be a concrete thing like a variable or more abstract one like a job pool. Now thinking of semaphore, semaphore is a mechanism to manage shared resources and guarantee access without congestion. Those two examples have a similarity which is a limited shared resource, the chess board and counters respectively.
In most cases, however, they’re all occupied and there’ll be long queues of people waiting to check out. If any of them is free, you can just go check out right away. Usually, there’s a limited number of counters. Another example is checkout counters in shopping malls. There’s only one chess board and only one person can make a move at a given time. If you’ve watched a chess contest, you probably know that each player will press a common timer before their turn in a match.
You can see analogies of semaphore in the real world in many places. Which will be discussed in detail in this post. Depends on the complexity of the app, different techniques are used to solve appropriate problems, and one of them is using semaphore to synchronize asynchronous jobs or orchestrate them among threads. Thanks to supports from high-level programming languages, libraries, and frameworks, it becomes more friendly and less error prone to work with. That helps the app be responsive and avoid sluggishness while using to bring a better experience to users.ĭispatching jobs to the corresponding thread is actually dealing with concurrent programming, a challenging topic as always. The rule of thumb for most of cases is to keep heavy, time-consuming jobs away from main thread yet ensure that calls to UIKit or UI-related happen in the main thread. Writing an iOS app nowadays is pretty simple, however, a performant one requires more effort in many aspects from algorithm optimization to system related actions.
0 kommentar(er)
