Concurrent programming and the Message Manager


#1

Hi all,
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:

  1. 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?
  2. Is it intended to be used for concurrency as an alternative to using Threads and such?
  3. 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)?
  4. 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!

-Mike


#2

Mike, you may want to rephrase your question if I give you the piece of information that everything the MessageManager does is on the main thread.

You can indeed request attention from other threads, but it all ends up on the main thread.

So it’s very useful, especially for anything involving the GUI or keeping your other threads from having to wait for the main thread at all, but not a panacea.

Juce has a ThreadPool and ThreadPoolJobs that I think are similar to GCD.

Bruce


#3

[quote=“Boozer”]- 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[/quote]

This all sounds like nonsense. It’s also important to understand that people in #iphone and #macos are mostly fanboys / religious zealots who have a fetish for all things Apple. My personal opinion is that the usage of proprietary APIs like those for OS X, iOS, or Windows, should be minimized or avoided entirely. Which is exactly why I prefer to use JUCE! Let Jules handle the dirty business of platform specifics, so that we as developers can concentrate on the important domain-specific bits.

Unfortunately, if you want a robust-looking native iOS app you will have to do some native coding, because JUCE is somewhat weak when it comes to building conforming apps for handhelds but this is largely in the user interface department.

I would be very cautious (and skeptical) taking advice from anyone who claims that you should “never ever use threads.”


#4

I’d second that. If they think that Grand Central Dispatch doesn’t use threads, they’ve missed the plot, and there’s great potential for disaster.

ThreadPoolJobs, as I mentioned, should be pretty similar. I wonder if ThreadPoolJobs plus ThreadQueue to call back to the main thread/app would round it out, but in principle, getting the job all the information it needs up front is the most efficient, especially with many jobs on the go.

Bruce


#5

I don’t use thread pools often, but I do have two other structures which I use often. They are the ParallelFor and the ThreadGroup. A parallel for loop calls a functor across multiple threads over some subset of the integers. The thread group executes a functor on several threads simultaneously. Note how these two approaches differ from a ThreadPool.

And there is the traditional ThreadWithCallQueue. Think of this as a ThreadPool with one thread. One of the added features is that you can have some background task that runs but can be pre-empted with more important work. This leverages the features of InterruptibleThread


#6

GCD’s big advantage is convenience. It was designed specifically to lower the cost of parallelizing small jobs (especially for less experienced or lazy coders). Beyond that, people preferring it to threads, reminds me of people who’ve read the functional programming marketing pieces and think that the lack of a for-next in their code some how means there’s no looping going on at all.

I slightly disagree with Vinn here though. I’d regard GCD as about on a level with using SSE instructions. It’s a small performance boost that can be gained with very little #ifdef’ing, but only for a very narrow window between “needs parallelizing” and “I really can’t be bothered.”


#7

[quote=“Bruce Wheaton”]Mike, you may want to rephrase your question if I give you the piece of information that everything the MessageManager does is on the main thread.

You can indeed request attention from other threads, but it all ends up on the main thread.

So it’s very useful, especially for anything involving the GUI or keeping your other threads from having to wait for the main thread at all, but not a panacea.

Juce has a ThreadPool and ThreadPoolJobs that I think are similar to GCD.

Bruce[/quote]

OK, so it’s not a thread pool then. I guess I’m just trying to get my head wrapped around what the MessageManager is. Is there a name for the kind of thing that it is? Is it like message dispatching in Objective-C or something?

I know that under the hood running on one thread, but is its idea to provide some kind of high-level abstract approach to concurrent programming, with asynchronous functor pushes onto a FIFO which are then called later? Or am I all wet?


#8

[quote=“TheVinn”][quote=“Boozer”]- 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[/quote]

This all sounds like nonsense. It’s also important to understand that people in #iphone and #macos are mostly fanboys / religious zealots who have a fetish for all things Apple. My personal opinion is that the usage of proprietary APIs like those for OS X, iOS, or Windows, should be minimized or avoided entirely. Which is exactly why I prefer to use JUCE! Let Jules handle the dirty business of platform specifics, so that we as developers can concentrate on the important domain-specific bits.[/quote]

Yes, this is basically what I’ve come to believe as well. I didn’t take their GCD advice too seriously, though if JUCE has something like it I’d be willing to experiment with it.

When you say “robust-looking,” do you mean “looks like a native iOS app?” Or do you mean “performs robustly?”

Yep. Noted. But I still wish I knew what the proper name for things like the MessageManager was.

(BTW, are people still using #juce IRC? I’ve been the only one in the chat room all day, but I dunno if it’s a fluke or if it’s dead now.)


#9

Looks and behaves like a native iOS app