Memory Allocation and Locking

BCS ao at pathlink.com
Thu Aug 21 21:36:23 PDT 2008


Reply to dsimcha,

> I guess this really is more of a C++ question then a D question, but
> it's kind of both, so what the heck?
> 
> Anyhow, I had some old C++ code laying around that I've been using,
> and I had added some quick and dirty multithreading of embarrassingly
> parallel parts of it to it to speed it up.  Lo and behold, it actually
> worked.  A while later, I decided I needed to extend it in ways that
> couldn't be done nearly as easily in C++ as in D, and it wasn't much
> code, so I just translated it to D.
> 
> First iteration was slow as dirt because of resource contention for
> memory allocation.  Put in a few ugly hacks to avoid all memory
> allocation in inner loops (i.e. ~= ), and now the D version is faster
> than the C++ version.
> 
> Anyhow, the real quesiton is, why is it that I can get away w/ heap
> allocations in inner loops (i.e. vector.push_back() ) in multithreaded
> C++ code but not in multithreaded D code?  I'm assuming, since there
> didn't seem to be any resource contention in the C++ version, that
> there was no locking for the memory allocation, but all of the
> allocation was done through STL rather than explicitly, so I don't
> really know.  However, the code actually worked like this, so I never
> really gave it much thought until today.  Is it just a minor miracle
> that this worked at all w/o me explicitly using some kind of lock?
> 
> By the way, if it's implementation defined, my C++ compiler is MinGW
> GCC 3.45.
> 

under C++ I'll guess that new is a thin skin on malloc, under D, new uses 
the GC. If one of these is thread safe and the other isn't, there's your 
issue. But I'm just guessing.




More information about the Digitalmars-d-learn mailing list