[D-runtime] gc_atomic

[Sean Kelly]

I added this new function today to solve a slightly obscure problem.  When a non-D thread adds itself to the list of GC scannable threads a Thread instance is allocated, some properties are set, and then the instance is added to the list.  From the time the GC lock is released after the initial allocation to the time the thread is added to the list, there are no GC-visible roots to the data.  The previous thread code tried to solve this by pre-allocating the thread instance for use by the next caller, but it had race and deadlock issues.  I tried adding the thread reference as a GC root, but that still left a race from when the memory was returned by the GC to when it was assigned to the root pointer.  There were a few other attempts, but all had similar issues.

What I really needed was a way to prevent a GC collection while the function executed.  GC.disable/enable were a decent alternative, but I still wasn't crazy about the idea that (admittedly incorrectly written code) could call enable() twice and screw everything up.  So I added gc_atomic() to have the GC basically guarantee that an operation would basically complete without GC interference, and leave the GC free to figure out what that meant.  I'm still wondering whether I should have just used enable/disable, so for now the function isn't exposed in core.memory.  Let me know what you think.