views:

66

answers:

4

I'm trying to implement an actor model of concurrency in Objective-C, because I want to avoid the infamous problems of shared mutable state, locks, semaphores, etc. It can be done, but it takes real discipline to avoid accidentally using shared state.

One way to enforce the shared-nothing rule is to use separate processes instead of separate threads, but I think that's overkill and will have a nasty overhead. What I'd really like is something that achieves the same end, but in a more light-weight fashion. Is there anything that fits this description?

A: 

Never fear the documentation! Take a look at NSOperation or a broader understanding via the Concurrency Programming Guide

--Frank

Frank C.
I'm already familiar with NSOperation, blocks, etc. This doesn't answer my question.
Tom Dalling
Then maybe a more succinct description (scenario) that provides better context would help.
Frank C.
A: 

A good approach for you is message passing. Two actors or threads set of a communication channel between them. The semantics of this channel can be complex or simple. A simple semantics is that messages are atomically written and atomically consumed. This can be used to implement a shared nothing approach, and is the the method of choice for many programming models.

This the model that Google's GO language uses.

Noah Watkins
+1  A: 

ActorKit

It's a little beta, but it works. Should give you a place to start worst case.

Joshua Weinberg
Thanks, looks interesting.
Tom Dalling
+1  A: 

The short answer to your question, sadly, is "No there's no OS facility that can enforce shared-nothing that's lighter weight than a process." In theory this would be an interesting direction for a static analysis tool (like clang) to take, but I'm not aware of any such tool today.

That said, have you had a close look at Grand Central Dispatch (aka libdispatch) and blocks?

My own experience has been that GCD and blocks dramatically simplify adhering to the discipline necessary for shared-nothing concurrency. You mention above that you're "already familiar with NSOperation, blocks, etc.", but I'd recommend really sitting down and exploring what you can do with them. Also, there are a lot of patterns possible with the dispatch APIs that aren't easily implemented on top of the NSBlockOperation / NSOperationQueue abstractions, so don't be afraid to delve into the underlying libdispatch APIs.

Kaelin Colclasure