Thread local and memory allocation

[Jason House]

Sean Kelly Wrote:

> On Oct 3, 2011, at 3:27 PM, Jason House wrote:
> 
> > Sean Kelly Wrote:
> >> There's another important issue that hasn't yet been addressed, which is that when the GC collects memory, the thread that finalizes non-shared data should be the one that created it.  So that SHARED flag should really be a thread-id of some sort.  Alternately, each thread could allocate from its own pool, with shared allocations coming from a common pool.  This would allow the lock granularity to be reduced and in some cases eliminated.
> > 
> > 
> > Why not run the collection for a single thread in the thread being collected? It's a simple way to force where the finalizer runs. It's a big step up from stop-the world collections, but still requires pauses.
> 
The world can't be stopped when finalizers run or the app can deadlock.  So the only correct behavior is to have the creator of a TLS block be the one to finalize it.

If only one thread is stopped, how will a deadlock occur? If it's a deadlock due to new allocations, doesn't the current GC already handle that?