TheKitchenSync - A Tool Belt for iOS Concurrency (opens in new tab)

(tech.cueup.com)

34 pointsasarazan12y ago19 comments

19 comments

As a small post-mortem, one interesting thing we learned while building this library: The reason Apple never included a read/write lock.

They're hard to get right (probably not a problem for Apple), and their overhead usually counterbalances any potential performance gains (possibly a problem for the unwary developer).

We've got some optimization work to do :-)

PaulHoule12y ago

It's pretty well known that reader-writer locks don't really work.

coolsunglasses12y ago

As opposed to what?

asarazanOP12y ago

As opposed to using a simple or recursive mutex while forgoing concurrent reads, in this case. There was an order of magnitude speed difference in raw lock/unlock performance.

Obviously this can still be useful in read-heavy systems where the lock has to be held for long spans, but for our synchronized collections, we switched to std::mutex, which was massively faster.

1 more reply

pjscott12y ago

As opposed to an ordinary lock which can be acquired only once. Compared to that, a read/write lock can have significantly lower lock contention, since multiple readers can acquire it at once.

rogerbinns12y ago

I love that Objective C/Foundation provides a distinction between mutable and non-mutable collections and tends to favour the latter. (I also hate they make it impossible to test which a collection is.)

Pet peeve: "insure" is used on the page. For some bizarre reasons Americans use that word when they mean "ensure". The difference is very important - insure is when you don't want something to happen and ensure is when you do!

andrewroycarter12y ago

You can test easily! [array isKindOfClass:[NSMutableArray class]] or [array respondsToSelector:@selector(insertObject:)]

rogerbinns12y ago

Have you actually tried it? Because the people who have (me included) found that both tests will return YES, yet when you try a mutable operation you get an exception.

http://stackoverflow.com/questions/1788690/objective-c-how-t...

http://www.cocoabuilder.com/archive/cocoa/224795-nsdictionar...

blakewatters12y ago

You cannot use `isKindOfClass:` to introspect an array like this. Most of the toll-free bridged foundation classes such as arrays/dictionaries/sets are implemented as class clusters.

aaronbrethorst12y ago

    they make it impossible to test which a collection is.

Couldn't you just test with the following?

    // NSMutableDictionary
    [dict respondsToSelector:@selector(setObject:forKey:]

    // NSMutableArray
    [arr respondsToSelector:@selector(addObject:)]

    // NSMutableString
    [str respondsToSelector:@selector(replaceCharactersInRange:withString:)]

    // NSMutableSet
    [set respondsToSelector:@selector(addObject:)]

Although, personally, I'd rather just, either at the class or method boundary depending on the circumstances, only expose the non-mutable variants.

rogerbinns12y ago

None of those work. (Try it.) The reason is that NSMutableXXXX is a wrapper around an underlying Core Foundation "object". You'll always get success from the Objective C level and then an exception when you try the action from the CF level.

Example SO question: http://stackoverflow.com/questions/1788690/objective-c-how-t...

Another example discussion: http://www.cocoabuilder.com/archive/cocoa/224795-nsdictionar...

asarazanOP12y ago

Hah, good catch! Fixing.

stcredzero12y ago

What about a subset of Hoare's CSP, as in Golang/Erlang? Objective-C already has support for immutables. How hard would it be to implement channels?

asarazanOP12y ago

That would certainly be an interesting project, although the performance implications on a mobile platform may be an issue (although that's becoming more moot with each generation).

In this case, however, our goal was to take common, familiar interfaces and idioms in Objective C, and make them safer/more powerful.

Something more like channels-like would be quite useful, but it would likely be published under a different project.

j / k navigate · click thread line to collapse

19 comments

asarazanOP12y ago

As a small post-mortem, one interesting thing we learned while building this library: The reason Apple never included a read/write lock.

They're hard to get right (probably not a problem for Apple), and their overhead usually counterbalances any potential performance gains (possibly a problem for the unwary developer).

We've got some optimization work to do :-)

PaulHoule12y ago

It's pretty well known that reader-writer locks don't really work.

coolsunglasses12y ago

As opposed to what?

asarazanOP12y ago

As opposed to using a simple or recursive mutex while forgoing concurrent reads, in this case. There was an order of magnitude speed difference in raw lock/unlock performance.

Obviously this can still be useful in read-heavy systems where the lock has to be held for long spans, but for our synchronized collections, we switched to std::mutex, which was massively faster.

1 more reply

pjscott12y ago

As opposed to an ordinary lock which can be acquired only once. Compared to that, a read/write lock can have significantly lower lock contention, since multiple readers can acquire it at once.

rogerbinns12y ago

andrewroycarter12y ago

You can test easily! [array isKindOfClass:[NSMutableArray class]] or [array respondsToSelector:@selector(insertObject:)]

rogerbinns12y ago

Have you actually tried it? Because the people who have (me included) found that both tests will return YES, yet when you try a mutable operation you get an exception.

http://stackoverflow.com/questions/1788690/objective-c-how-t...

http://www.cocoabuilder.com/archive/cocoa/224795-nsdictionar...

blakewatters12y ago

You cannot use `isKindOfClass:` to introspect an array like this. Most of the toll-free bridged foundation classes such as arrays/dictionaries/sets are implemented as class clusters.

aaronbrethorst12y ago

    they make it impossible to test which a collection is.

Couldn't you just test with the following?

    // NSMutableDictionary
    [dict respondsToSelector:@selector(setObject:forKey:]

    // NSMutableArray
    [arr respondsToSelector:@selector(addObject:)]

    // NSMutableString
    [str respondsToSelector:@selector(replaceCharactersInRange:withString:)]

    // NSMutableSet
    [set respondsToSelector:@selector(addObject:)]

Although, personally, I'd rather just, either at the class or method boundary depending on the circumstances, only expose the non-mutable variants.

rogerbinns12y ago

Example SO question: http://stackoverflow.com/questions/1788690/objective-c-how-t...

Another example discussion: http://www.cocoabuilder.com/archive/cocoa/224795-nsdictionar...

asarazanOP12y ago

Hah, good catch! Fixing.

stcredzero12y ago

What about a subset of Hoare's CSP, as in Golang/Erlang? Objective-C already has support for immutables. How hard would it be to implement channels?

asarazanOP12y ago

That would certainly be an interesting project, although the performance implications on a mobile platform may be an issue (although that's becoming more moot with each generation).

In this case, however, our goal was to take common, familiar interfaces and idioms in Objective C, and make them safer/more powerful.

Something more like channels-like would be quite useful, but it would likely be published under a different project.

j / k navigate · click thread line to collapse