Brian Mckinnon <[EMAIL PROTECTED]> 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.
_______________________________________________
help-gplusplus mailing list
help-gplusplus@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gplusplus
