valid uses of shared

[Steven Schveighoffer]

On Thu, 07 Jun 2012 22:16:21 -0400, Robert DaSilva <spunit262 at yahoo.com>  
wrote:


> You're forgetting about Global data.

I wasn't so much forgetting it as I was ignoring it :)

My thought on that is that the shared keyword in that case is truly a  
storage class.  It's the one place where having a value-type based shared  
value makes sense.  If we had some kind of synchronized/shared pairing,  
the compiler would have to allocate mutex space for that too.

> I think rather the head shared should be striped as this fits better  
> with how D treats meaningless specifiers.

I don't think we can do that with type constructors, but I'm not sure.   
I'm certainly against it, as I am against the current abuses of that  
methodology.

> And trying to put structs that contain shared data on the stack should  
> be illegal.

First, I can't imagine that you'd actually need a block on the heap that  
was partially thread-local and partially shared.  So allowing  
partially-shared types does not make sense to me.  For the cases where it  
may make sense, a value-type + shared pointer might work, or a heap block  
of TLS data which has a member pointing to another heap block of shared  
data could make sense.

Can you think of good use cases that show it is important to have hybrid  
blocks?

Second, I kind of like the idea that the monitor for the data in the block  
protects the entire block.  This would not make sense if part of the block  
is not shared.

-Steve