Something needs to happen with shared, and soon.

[Jonathan M Davis]

On Tuesday, November 13, 2012 14:33:50 Andrei Alexandrescu wrote:
> As long as a cast is required along the way, we can't claim victory. I
> need to think about that scenario.

At this point, I don't see how it could be otherwise. Having the shared 
equivalent of const would just lead to that being used everywhere and defeat 
the purpose of shared in the first place. If it's not segregated, it's not 
doing its job. But that leaves us with most functions not working with shared, 
which is also a problem. Templates are a partial solution, but they obviously 
don't work for everything.

In general, I would expect that all uses of shared would be protected by a 
mutex or synchronized block or other similar construct. It's just going to 
cause problems to do otherwise. There are some cases where if you can 
guarantee that writes and reads are atomic, you're fine skipping the mutexes, 
but those are relatively rare, particularly when you consider the issues in 
making anything but extremely trivial writes or reads atomic.

That being the case, it doesn't really seem all that unreasonable to me for it 
to be normal to have to cast shared to non-shared to pass to functions as long 
as all of that code is protected with a mutex or another, similar construct - 
though if those functions aren't pure, you _could_ run into entertaining 
problems when a non-shared reference to the data gets wiled away somewhere in 
those function calls.

But we seem to have contradictory requirements here of trying to segregate 
shared from normal, thread-local stuff but are still looking to be able to use 
shared with functions intended to be used with non-shared stuff.

- Jonathan M Davis