boost::condition_variable problem
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 4 of 4

Thread: boost::condition_variable problem

  1. #1
    Join Date
    May 2007
    Location
    Scotland
    Posts
    1,121

    boost::condition_variable problem

    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.
    Last edited by PredicateNormative; February 21st, 2013 at 08:41 AM.

  2. #2
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    3,762

    Re: boost::condition_variable problem

    this sounds like a synchronisation issue in the threads. You're probably accessing/modifying a global/shared variable/resource on multiple threads without this being properly protected by a synchronisation object.

    There is unfortunately no really easy way out of this other than "oldfashioned" bughunting with a good debugger, a focussed mind and a lot of time.

  3. #3
    Join Date
    Nov 2003
    Posts
    1,787

    Re: boost::condition_variable problem

    http://www.boost.org/users/history/

    This was the only fix that jumped out at me: https://svn.boost.org/trac/boost/ticket/6200

    The smallest complete app that reproduces the issue is always nice. Or at least, the exact boost code where the spinning or bad behavior is occurring.

    gg

  4. #4
    Join Date
    May 2007
    Location
    Scotland
    Posts
    1,121

    Re: boost::condition_variable problem

    Sorry about my very delayed response - things got pretty manic at work. Due to time constraints I have had to apply a patch (pretty much re-implemented the offending bit of code in a different, albeit less efficient way), however, I have raised a ticket against the original file, since I don't like plastering over a problem without understanding the cause.

    As of yet I have been unable to create a minimal complete app that reproduces the problem - all of the attempts that I have made so far have failed, in that the minimal apps have all worked as expected. This leads me to believe that I might be "barking up the wrong tree" and that the cause of the bug is possibly else where - thankfully they haven't happened too often, but I hate threading bugs!

    I tried updating to boost 1.53, but that hasn't made a difference. I'm now doubting that the problem is with boost, but I could be wrong. I have created a number of classes that wrap around boost thread to make threading easier and less error prone, these classes are used everywhere in our code. I would expect that if these threading classes are the problem that I would have seen the issue before now (they've been around for a good while and used in a good many applications), so although I'm not ruling the possibility out, I'm thinking that the threading issue is probably else where.

    I'll keep looking and let you know if I fix it.

    Thanks,

    Andrew

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Azure Activities Information Page

Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center