On Wednesday, 8 July 2015 at 10:10:58 UTC, Jonathan M Davis wrote:
On Wednesday, 8 July 2015 at 09:54:01 UTC, ketmar wrote:
On Wed, 08 Jul 2015 09:43:38 +0000, wobbles wrote:
Ok, so we should prioritise using 'shared' over __gshared as
much as possible. Good to know!
only `shared` is PITA...
The primary advantage of shared is that it allows most
everything to be thread-local.
Though arguably, shared _should_ be a bit of a pain, since its
usage should normally be very restricted. But we do need to
revisit shared and figure out what we want/need to do with it.
Synchronized classes as described in TDPL were never even
implemented (though I contest that they really make shared
usable in any kind of sane way; I really don't see how you can
do anything other than really basic stuff with shared without
requiring that the programmer deal with the locks and casting
properly on their own). So, more work needs to be done there
even if it's figuring out what shared _isn't_ going to be doing.
Really though, one of the bigger problems is dealing with
allocation and deallocation of shared objects and passing
objects across threads, since we keep wanting to be able to do
stuff like have thread-specific allocators, but the way shared
currently works doesn't actually allow for it. :|
Regardless, while I would very much like to see shared properly
ironed out, I'm _very_ grateful that thread-local is the
default in D. It's just so much saner.
- Jonathan M Davis
I still couldn't have found my answer though. I have three
different use cases, one is missing in the language.
1. Thread-local object.
2. Shared, but implemented as not to be synchronised.
3. Shared, and implemented to be synchronised.
There is no simple way to design a class, so that you can
implement it for points 2 and 3. The only way is to use _gshared
with point one to solve it.
I use shared in many of my classes. Thus I experience different
situations.
