boost::condition_variable problem

[PredicateNormative]

I have written a fairly large application with a small team of software engineers (~237kloc) over the last four years. In our development environment under Windows, the bug that I'm about to describe does not occur. However, when running on our target OS (Fedora 15 32bit with boost 1.47) the bug does occur. The application has a fair number of threads and use a lot of boost::condition_variables, however, I have hit the problem where calling condition_variable::wait() in one of the threads utilises pretty much 100% of the core on which the thread is running. It's almost as if condition::wait() is calling an unrestricted while loop under the hood - clearly something has gone wrong. To mitigate the idea that there is something wrong with the classes that are carry out the threading, if I take them at test them as a block in isolation to the rest of the application, the code behaves perfectly, so I'm pretty convinced it is not something that I have done... or at least, if it is, it really isn't obvious.

So, I thought I'd ask, has anyone else ever had this problem with condition_variables? If so, what was the solution? I'm pretty much out of ideas. It seems to me that it is a bug in boost or perhaps even less likely, the OS (perhaps there is a limit to the number of condition_variables that can be supported and I have exceeded that limit???).

Our target system is an Intel i7 based machine running Fedora 15 (32 bit) with boost 1.47... I guess I could compile the latest version of boost and see if the behaviour is still the same, but past that, I really have no idea what could cause the problem.

Any ideas would be much appreciated.