Re: [Boost-users] Compatibility between shared_ptr and Rational RoseRT

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-04-26 16:42:08

Ross Manges wrote:
>> Attaching the code (in whatever form is convenient to you) is fine.
> OK, I've attached some sample code I made up to show the kind of
> problems I'm having (the code doesn't do anything useful).  Running
> this code results in the backtrace below.  I am aware that this code
> breaks the condition that the shared_ptr needs to have exclusive
> writing modifications; however, I am unsure how to fix the code to
> make it correct.  Please let me know if you have any suggestions,
> thanks! (BTW, I'm running against the Boost CVS which I downloaded
> on Fri, Apr 22nd;

You should probably redownload since the CVS contained some slightly broken 
versions for a short time. :-)

> if I run against version 1_32, the backtrace is in the
> scope_lock instead of atomic_increment)

.. although your problem probably lies elsewhere.

I'm not seeing any violations of the rules in your code; the problem is 
probably more mundane:

ElementPtr SimpleQueue::pop() {
    ElementPtr retElem;

    if(!Queue.empty()) {

Since this check is not protected by a mutex lock, it is possible for two or 
more threads to test for emptiness simultaneously when the queue contains 
only one element...

        boost::mutex::scoped_lock scoped_lock(mutex);
        retElem = Queue.back();

... and then the second and subsequent threads will access an invalid 
.back(). This may explain your crash.

        Queue.pop_back();
    }
    else {
        cout <<"******************* EMPTY QUEUE" << endl;
    }
    return retElem;
}