How many is too many for create dispatch_queues in GCD (grand central dispatch)? : <p>There is a wonderful article about a lightweight notification system built in Swift, by Mike Ash: (<a href="https://www.mikeash.com/pyblog/friday-qa-2015-01-23-lets-build-swift-notifications.html" rel="noreferrer">https://www.mikeash.com/pyblog/friday-qa-2015-01-23-lets-build-swift-notifications.html</a>).</p>

<p>The basic idea is you create objects that you can "listen" to i.e. invoke a callback on when there is some state change.  To make it thread-safe, each object created holds its own dispatch_queue.  The dispatch_queue is simply used to gate critical sections:</p>

<pre><code>dispatch_sync(self.myQueue) {
    // modify critical state in self
}
</code></pre>

<p>and moreover it likely won't be in high contention.  I was kind of struck by the fact that <em>every</em> single object you create that can be listened to makes its own dispatch queue, just for the purposes of locking a few lines of code.</p>

<p>One poster suggested an OS_SPINLOCK would be faster and cheaper; maybe, but it would certainly use a lot less space.</p>

<p>If my program creates hundreds or thousands (or even tens of thousands of objects) should I worry about creating so many dispatch queues?    Probably most won't ever even be listened to, but some might.</p>

<p>It certainly makes sense that two objects not block each other, i.e. have separate locks, and normally I wouldn't think twice about embedding, say, a pthread_mutex in each object, but an entire dispatch queue?  is that really ok?</p>
