Memory Allocation and Locking

[Sean Kelly]

dsimcha wrote:
> But D's malloc appears to require locking even when memory is available, just to
> allocate it.  Heck, it even synchronizes to check the capacity of an allocated
> block, which (I'm guessing) means every ~= requires a synch if the code is
> multithreaded, even if no realloc ends up being necessary.  I base this on reading
> the GC implementation.

You're right.  But it's likely that an allocator for C++ would have to 
do the same thing, unless you're talking about a special-purpose one 
like HOARD.  Also, the Tango GC will only lock on this mutex if the app 
is actually multithreaded.  Single-threaded apps skip the locking 
process.  The Phobos GC does this as well, but I recall finding some 
gaps in its coverage for this feature.

 > I assume that allocating via builtin arrays is basically a
> thin layer on top of D's malloc.  Here's the Phobos implementation.  For those who
> haven't looked at this, the function thread_needLock just returns true if more
> than 1 thread is currently running.  Haven't looked at Tango b/c, unfortunately,
> it's not on D2 yet.
> 
>     void *malloc(size_t size)
>     {
>         if (!size)
>         {
>             return null;
>         }
> 
> 	if (!thread_needLock())
> 	{
> 	    return mallocNoSync(size);
> 	}
> 	else synchronized (gcLock)
> 	{
> 	    return mallocNoSync(size);
> 	}
>     }

thread_needLock() was actually cribbed from Tango a while back.  Phobos 
used to do something like "Thread.getAll.length > 1."  The effect is 
essentially the same though.

> Bottom line is, it's mostly just a curiosity/future reference question, since with
> a few tweaks, the D version is now *faster* than the C++ version, but how can C++
> get away w/ concurrent memory allocations while D can't, or should my C++ version
> never have worked in the first place?

I don't think it's the locking that's an issue but rather the collection 
cycles plus possibly the need to obtain additional pools from the OS.


Sean