10

My application makes heavy use of GCD, and almost everything is split up in small tasks handled by dispatches. However, the underlying data model is mostly read and only occasionally written.

I currently use locks to prevent changes to the critical data structures while reading. But after looking into locks some more today, I found NSConditionLock and some page about read-write locks. The latter is exactly what I need.

I found this implementation: http://cocoaheads.byu.edu/wiki/locks . My question is, will this implementation work with GCD, seeing that it uses PThreads?

bdash
  • 18,110
  • 1
  • 59
  • 91
Erik S
  • 1,939
  • 1
  • 18
  • 44

2 Answers2

27

It will still work. pthreads is the threading API which underlies all of the other thread-using APIs on Mac OS X. (Under that there's Mach thread activations, but that's SPI, not API.) Anyway, the pthreads locks don't really require that you use pthreads threads.

However, GCD offers a better alternative as of iOS 5: dispatch_barrier_async(). Basically, you have a private concurrent queue. You submit all read operations to it in the normal fashion. You submit write operations to it using the barrier routines. Ta-da! Read-write locking.

You can learn more about this if you have access to the WWDC 2011 session video for Session 210 - Mastering Grand Central Dispatch.

Ken Thomases
  • 88,520
  • 7
  • 116
  • 154
  • 1
    Ah, I had read about the barriers, but at the time could not think of a practical application (I barely used multithreading back then) and forgot all about them. Thanks, I will try to see if I can use that! – Erik S Apr 19 '12 at 19:09
  • 4
    Mike Ash also provides a nice example of how to accomplish reader-writer synchronization using GCD. http://www.mikeash.com/pyblog/friday-qa-2011-10-14-whats-new-in-gcd.html – Quinn Taylor Apr 03 '13 at 07:15
2

You might also want to consider maintaining a serial queue for all read/write operations. You can then dispatch_sync() writes to that queue to ensure that changes to the data model are applied promptly and dispatch_async() all the reads to make sure you maintain nice performance in the app.

Since you have a single serial queue on which all the reads and writes take place you ensure that no reads can happen during a write. This is far less costly than a lock but it means you cannot execute multiple 'read' operations simultaneously. This is unlikely to cause a problem for most applications.

Using dispatch_barrier_async() might mean that writes you make take an arbitrary amount of time to actually be committed since all the pre-existing tasks in the queue have to be completed before your barrier block executes.

mjmdavis
  • 2,583
  • 3
  • 19
  • 16
  • Hmm, I didn't even realise async dispatch was possible on a serial queue. This sounds like an interesting idea... All reads are reasonably small edits, though writes usually mean reading, editing and then saving the data again. – Erik S May 06 '12 at 09:17
  • 8
    Usually, you do the opposite of what's suggested here. Reads usually have to be submitted synchronously, since you often need to have the result before returning to the caller. Writes can be done asynchronously, since the caller only cares that the state observable from the outside is consistent with the date having been written, which it is because no read can proceed until the write has completed because the queue is serial. Doesn't help with multiple readers, as noted. – Ken Thomases May 12 '12 at 03:01
  • Also dispatch_barrier_async() will/may eventually deadlock, like this: https://stackoverflow.com/questions/36634315/dispatch-barrier-sync-always-deadlocks – Olof_t Sep 12 '18 at 06:23