Yes, that's good. But you can't have two threads accessing the same data at the same time, which is called a race condition. It means one thread can write some data and the other thread reading it at the same time, resulting in data corruption among other things...
I never use multi-threaded code this way so I'll take your word for it. Usually I give my threads complete ownership over inherited data ie I try to avoid directly sharing data, but then my use for threads is probably a bit different than others.
I meant suitable Windows API. There's no good function to release a lot of data at once.
I presume you mean there is no suitable API for a GC in C++? It's not an all or nothing proposition really. I choose to make all new classes children of the GC class so that new is automagically GC'd for them. I otherwise don't touch what I use from std and avoid using new with these objects. I also use new (GC) for raw low level array allocation. Works for me so far and is not particularly complicated.
What's complicated actually are the crazy semantics of C++. Once you understand it, it's not so bad, and I'm even starting to enjoy it. However it's quite a bit easier and more productive to program in languages with a built in GC. Compare say, Java, D, or some of the functional languages such as Haskell, Ocaml or even Lisp/Scheme.
Other than D, however these languages underperform computationally and D is not yet mature enough to have good development and debugging tools. Thus C++ is still pretty attractive (especially if I can have a garbage collector too :) ).