• Etienne (21/21) Nov 16 2014 I always wondered why we would use the shared keyword on GC allocations
• Etienne (2/2) Nov 16 2014 I realize this shouldn't belong in D.learn :)

Etienne <etcimon gmail.com> writes:

I always wondered why we would use the shared keyword on GC allocations 
if only the stack can be optimized for TLS Storage.

After thinking about how shared objects should work with the GC, it's 
become obvious that the GC should be optimized for local data. Anything 
shared would have to be manually managed, because the biggest slowdown 
of all is stopping the world to facilitate concurrency.

With a precise GC on the way, it's become easy to filter out allocations 
from shared objects. Simply proxy them through malloc and get right of 
the locks. Make the GC thread-local, and you can expect it to scale with 
the number of processors.

Any thread-local data should already have to be duplicated into a shared 
object to be used from another thread, and the lifetime is easy to 
manage manually.

SomeTLS variable = new SomeTLS("Data");
shared SomeTLS variable2 = cast(shared) variable.dupShared();
Tid tid = spawn(&doSomething, variable2);
variable = receive!variable2(tid).dupLocal();
delete variable2;

Programming with a syntax that makes use of shared objects, and forces 
manual management on those, seems to make "stop the world" a thing of 
the past. Any thoughts?

Etienne <etcimon gmail.com> writes:

I realize this shouldn't belong in D.learn :)

http://forum.dlang.org/thread/m4aahr$25qd$2 digitalmars.com#post-m4aahr:2425qd:242:40digitalmars.com