We're writing an iPad app with quite a lot of background processing all of which is written in a set of C++ libraries. These libraries work fine on Linux, Mac and Windows but on the iPad they only work in debug builds.
In release builds, it looks like when the first sub-thread is being spun up it either never actually starts, or it doesn't get far enough in its processing to allow the main thread to continue (it isn't very obvious from the debugger if the thread is actually starting or not due to the normal problem of using break points in release builds).
Looking in the debugger the main thread sits in boost::thread::start_thread (actually inside boost::detail::yield within boost::detail::spin_lock::lock).
The CPU isn't at 100% so it doesn't appear that the spin lock is starving the creation of the new thread.
We've tried both Boost 1.42 and Boost 1.44 and they both behave the same way. Both iOS 3.2 and 4.2 both fail with release builds.
What are we likely doing wrong, or is this a known not-working configuration?
We've now worked this out. The problem is in the build options, and the clue is that it is the spin locks that are failing.
It turns out that there is an ARM implementation of the spin lock which is used in non-thumb builds. Because of the way that the thumb builds are done it is very easy to mix thumb and non-thumb builds (i.e., build Boost without thumb and have xCode build with thumb). This is what we were doing, and this means that the spin lock will never get signalled and will just block forever.
So, to solve this, make sure that you are using the same thumb build options for all of your libraries!
This thread discusses the problem: http://groups.google.com/group/boost-list/browse_thread/thread/7dc1e80659182ab3