Re: Operators 'new', 'delete' and thread safety.

[Brian Mckinnon]

On Apr 18, 9:52 am, Paul Pluzhnikov <ppluzhnikov-...@charter.net>
wrote:
> Brian Mckinnon <bpmckin...@gmail.com> writes:
> >> >> Is it safe to use operators 'new' and 'delete' in a multithreaded
> >> >> programs, that is: are those operators thread-safe in a current
> >> >> implementation of g++?
>
> > I'm actually having a problem with what appears to a new/delete thread
> > safety issue, and this is actually the second time it has happened to
> > me.
>
> You can write thread-unsafe code even if new/delete are safe.
> IOW, look for a bug in *your* code.
>
> > The last time it happened to me I did a pretty heavy analysis on
> > the problem, and I saw that memory addresses which had been freed by
> > one thread were being used by another.
>
> So you are still using memory after it has been freed.
>
> That's one of the most common C/C++ mistakes, and has nothing to
> do with new/delete safety. Example of buggy code:
>
>       int *global;
>
>    T1                                 T2
>
>    while (1) {                        while(1) {
>      global = new int(1);               if (global[0]) {
>      // do something                      // do something
>      delete global;                     }
>    }                                  }
>
> Above there is a race, and T2 could sometimes be reading deleted
> memory.
>
> > The only way I could fix the problem was to use a thread
> > safe factory to create and free the memory.
>
> You probably simply changed timing, so you can no longer observe
> the race (IOW, the bug is still there, but its symptoms aren't).
>
> > The original problem
> > happened when I was actually calling new and delete on a bunch of
> > objects, while my current problem occurs with a std::vector of
> > std::vector's.
>
> > This seems crazy to me though. The only thing I can think is that new
> > and delete are not thread safe, but I know that can't be true.
>
> You should be thinking: "do I have proper mutex protection for all
> variables shared between threads?"
>
> In addition, for STL containers you should be thinking: "do I have
> any iterators, pointers or references that may be invalidated by
> container modification operations?" Compile all your code with
> -D_GLIBCXX_DEBUG -- this turns on g++ STL debugging facilities that
> may find the bug for you [1].
>
> > Is
> > there a way to override the new and delete functions, or enable some
> > form of malloc debugging so I can at least try and identify the
> > issue.
>
> You can override global new/new[]/delete/delete[], and add locking
> (pointless) or logging (could be useful).
>
> Cheers,
>
> [1] This can only catch invalid iterators, but not pointers/references.
> For the latter, try new "STL checking mode" of Insure++ (www.parasoft.com).
>
> --
> In order to understand recursion you must first understand recursion.
> Remove /-nsp/ for email.

I'm sure it is a race condition or memory overflow, but the data
streams are very independent.  I'm using the program to process stereo
cameras, so the two threads don't share any information until they
both complete a bunch of image preprocessing.  The error occurs during
the preprocessing stage, normally during the first frame, so there
"should" be no information shared between the two threads.

The factory I used to generate the objects (If my memory serves me
right) was a class with static claim and release functions.  The
functions both used a static mutex.  The release function would
actually place the object onto a vector to be reused.  The claim
function either popped the top object off the vector, or created a new
object when the vector was empty.  My goal was to test how things
would run if I stopped calling delete on the object.

I'll play with this some more tonight (I'm posting from work so I
can't test the code).  I'll see what valgrind says, and try what
you've suggested.