I’ve been getting heavier into the nitty gritty of concurrent programming this past year. After spending quite a bit of time trying to optimize a simple thread-based architecture I’ve had going with my app, I got some recommendations for more avant-garde things from other people:
- Vinnie Falco recommended for me in #JUCE that I look at threadqueues instead
- Various people have told me to try setting up some Erlang/Haskell type architecture
- The freenode #iPhone people are adamant that I should never ever use threads and should use Grand Central Dispatch for everything
One thing I just realized is that Juce has an event dispatch loop going, so I realized I might want to experiment with using that for concurrency rather than dealing with threads manually.
So I’m trying to figure out what sort of architecture the MessageManager is built on and if people are using it for concurrency. The four specific questions I have are:
- Is it based on the thread pool pattern, like Apple’s Grand Central Dispatch? If not, what sort of concurrency architecture is it built around?
- Is it intended to be used for concurrency as an alternative to using Threads and such?
- Do people find it’s simpler and faster than dealing with Threads and locks manually (or is the latter faster if you’re smart enough to avoid deadlocking and high-contention lock fights)?
- Is the message queue a FIFO? More strongly, are messages actually delivered to their recipients in the same order that the individual calls to postMessage() are made?
Thanks for the info, I’m quite excited about the thought of diving into the next century with dispatch loops for concurrency, so I can stop worry about those philosophers dining all the time!