TheKitchenSync - A Tool Belt for iOS Concurrency

TheKitchenSync - A Tool Belt for iOS Concurrency(tech.cueup.com)

34 points by asarazan 13 years ago | 19 comments

asarazan 13 years 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 :-)

PaulHoule 13 years ago | |

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

coolsunglasses 13 years ago | |

As opposed to what?

asarazan 13 years 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.

pjscott 13 years 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.

rogerbinns 13 years 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!

andrewroycarter 13 years ago | |

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

rogerbinns 13 years 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...

blakewatters 13 years 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.

aaronbrethorst 13 years 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.

rogerbinns 13 years 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...

asarazan 13 years ago | |

Hah, good catch! Fixing.

stcredzero 13 years 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?

asarazan 13 years 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.

// NSMutableDictionary [dict respondsToSelector:@selector(setObject:forKey:] // NSMutableArray [arr respondsToSelector:@selector(addObject:)] // NSMutableString [str respondsToSelector:@selector(replaceCharactersInRange:withString:)] // NSMutableSet [set respondsToSelector:@selector(addObject:)]