mikeash.com pyblog/friday-qa-2011-10-14-whats-new-in-gcd.html comments

jjt - 2017-01-02 20:41:08

Mon, 02 Jan 2017 20:41:08 GMT

@bbum NSDictionary, the read-only version of NSMutableDictionary, is listed as Thread-Safe.

James Alan Bush - 2016-09-06 16:48:59

Tue, 06 Sep 2016 16:48:59 GMT

Terrific post! Very concise, accurate. One question, though: how would one construct a CMSampleBuffer from a dispatch_data_t object?

That's a big one, I know; but, it would solve a big problem for those needing to read assets (videos) without using AVFoundation...

Valeriy Van - 2016-05-10 12:47:23

Tue, 10 May 2016 12:47:23 GMT

Description of dispatch_data_apply doesn't give guarantee applier block will not be fired concurrently. In that case StringFromDispatchData function will crash.

bbum - 2016-03-07 18:36:54

Mon, 07 Mar 2016 18:36:54 GMT

Mike--

The collection class documentation does not make any claims as to the thread safety of NSMutableDictionary in a read-only role.

https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Multithreading/ThreadSafetySummary/ThreadSafetySummary.html

jasna - 2015-05-23 20:43:39

Sat, 23 May 2015 20:43:39 GMT

well, it's way late but replying to don fulano:

I am little unclear why the write block is dispatch_barrier_async and not a dispatch_barrier_sync. Don't you need it to be sync to make sure the data is finished writing before returning from the block. Won't the async return before the block is completed.

assuming this is about thread-safe cache code above, you can afford to do async and return immediately, because all your getters are protected by dispatch_sync on the same dispatch queue; so your getter will block until earlier dispatch_barrier_async operation completes

HS - 2014-02-07 09:19:30

Fri, 07 Feb 2014 09:19:30 GMT

@mikeash: I was wondering how you get such type of information. You are an amazingly genius!

roshni - 2013-11-14 12:41:40

Thu, 14 Nov 2013 12:41:40 GMT

@mikeash I am bit confuse when exactly to use sync and async,Can you elaborate on the same . thanks

tikhop - 2012-08-21 09:18:42

Tue, 21 Aug 2012 09:18:42 GMT

@mikeash become much clearer, thanks for the answer!

I also had another test and it showed a lot more interesting: GCD 2x time faster.

http://stackoverflow.com/questions/11920584/mutating-array-while-reading-not-enumerating/11921122#11921122

mikeash - 2012-08-13 18:14:06

Mon, 13 Aug 2012 18:14:06 GMT

tikhop: The semantics are quite different. A custom concurrent queue using barriers will allow multiple active readers simultaneously, or one writer, while @synchronized only ever allows a single thread to be within the synchronized block at a time (with the same lock object). Additionally, using a dispatch queue means that your locked operations can be run asynchronously, whereas code must always wait for a @synchronized block to complete before continuing. There's nothing wrong with @synchronized, and if it fits your needs then by all means use it.

Andrew: I don't understand the relevance of posting the declaration for dispatch_get_global_queue. In any case, the documentation is quite clear that the dispatch_barrier_async function and its friends are available on 10.7+ and 4.3+.

Andrew - 2012-08-13 12:45:57

Mon, 13 Aug 2012 12:45:57 GMT

This gentleman on stackoverflow has posted the header files for some of these APIs which suggest that these tools were actually available in iOS 4, not iOS 5. i'm a little confused so any assistance is appreciate; many resources around the web suggest only Lion and iOS 5 feature some of these options:

http://stackoverflow.com/a/11926625/768472

tikhop - 2012-08-12 11:10:22

Sun, 12 Aug 2012 11:10:22 GMT

Why I should use dispatch_barrier_async instead of @synchronized. I try both approach and @synchronized method little bit faster.

mikeash - 2012-04-04 14:31:08

Wed, 04 Apr 2012 14:31:08 GMT

It doesn't matter if the data isn't written before the method completes. The only way to retrieve data from the cache is to use the dispatch queue, which will wait until all previous writes are complete.

Don Fulano - 2012-04-04 03:48:59

Wed, 04 Apr 2012 03:48:59 GMT

David H - 2011-11-16 15:21:37

Wed, 16 Nov 2011 15:21:37 GMT

Your information on "concurrent queue and barriers" is just EXCELLENT and a huge help to me (who is using gobs of operations and async dispatches on an iPhone app.

Note that DISPATCH_QUEUE_PRIORITY_BACKGROUND is also available on iOS 4.

David

mikeash - 2011-10-19 17:59:43

Wed, 19 Oct 2011 17:59:43 GMT

Under ARC you need to explicitly reference the data object in the block in some other way, like [nsdata self]. It makes no difference at all whether the captured variable is decorated with __block or not.

Jean-Daniel - 2011-10-19 17:22:24

Wed, 19 Oct 2011 17:22:24 GMT

To follow up Tom suggestion, using __block has an other big advantage, it works with ARC, where explicit release call is prohibited.

mikeash - 2011-10-18 14:30:18

Tue, 18 Oct 2011 14:30:18 GMT

Makes sense, it's going to be pretty fast either way.

Tom M - 2011-10-18 07:37:19

Tue, 18 Oct 2011 07:37:19 GMT

It was more an observation, and as you say, it would be foolish to assume which is faster. You got me curious enough to have a quick look, and as it happens it seems to be a wash. Certainly for NSData objects (of the size I was testing, which were pretty small) the difference wasn't statistically different. On multiple runs, it went either way. A quick look with Instruments shows that it's just not spending enough time in the block copy helper to be meaningful compared to other big ticket items (like objc_msgSend, and memory operations).

Steven Fusco - 2011-10-17 18:10:36

Mon, 17 Oct 2011 18:10:36 GMT

You can get to priority background and the new barrier API in iOS 4.3, no need to wait for 5. It's marked __OSX_AVAILABLE_STARTING(__MAC_10_7,__IPHONE_4_3)
in the header

mikeash - 2011-10-16 04:01:23

Sun, 16 Oct 2011 04:01:23 GMT

True, but it's not a problem. Are you suggesting that using __block will be faster? I'd want to see measurements on that before accepting it if that's the case, since __block captured variables have additional overhead compared to the regular kind.

Tom M - 2011-10-16 02:22:24

Sun, 16 Oct 2011 02:22:24 GMT

Great summary of the new GCD features.

One minor point: block capture in CreateDispatchDataFromNSData will result in a redundant retain/release taking place for the copied nsdata. Storing the copy in a __block NSData* auto variable would eliminate that.

mikeash - 2011-10-14 21:56:41

Fri, 14 Oct 2011 21:56:41 GMT

The trouble with thread-safe (note, not reentrant, subtle difference) containers is that they're difficult to create, tend to be slow, and leave their users open to nasty threading bugs anyway.

For example, you might write a method to getthe first item of an array:

- (id)firstItem { return [array count] ? [array objectAtIndex: 0] : nil; }

However, with an array being used by multiple threads, this code is unsafe even if the array itself is nominally thread safe, because another thread could remove the last object from the array between the check and the fetch.

Fundamentally, thread safety doesn't compose. It's painful, but there we are.

What you'd really need is something that allowed for transactions on these containers, which would be really useful but fairly complex, or something which allowed locking around multiple operations which need to be atomic, which works but basically puts you right back to square one.

Brent Gulanowski - 2011-10-14 13:36:53

Fri, 14 Oct 2011 13:36:53 GMT

So, when do we get foundation containers and file abstractions that have (optional) integrated support for re-entrancy based on this? Seems like a no-brainer to encapsulate the custom dispatch queue right into the object. Until then, I guess we use custom wrappers. (NSMutableDictionary<-(NS)ReentrantDictionary?)