Generality creep

Jonathan M Davis newsgroup.d at jmdavisprog.com
Mon Apr 1 10:11:04 UTC 2019


On Monday, April 1, 2019 1:08:29 AM MDT FeepingCreature via Digitalmars-d 
wrote:
> On Sunday, 31 March 2019 at 22:25:30 UTC, Manu wrote:
> > Sure. But in the meantime, fix the objective bug with the
> > current semantics where you can read/write un-protected data
> > freely. Right now. Please for the love of god.
>
> Apropos "things to do right now", to derail the thread a little
> in my own interest, could I  again ask to decouple synchronized
> and shared for the time being? There is literally no way to write
> a class that has both threadsafety and invariant-safety right
> now, because D has no way to pull invariants into the class body
> without pulling in the `shared` mess. Look, if I'm using
> synchronized(this), as a rule I don't *care* about shared,
> because I'm inherently using another *kind* of thread safety to
> atomic primitives.
>
> Uncoupling shared from synchronized at the class level would make
> synchronized classes actually usable and useful without
> restructuring the entire class for no gain.

How is synchronized unrelated to shared? shared is part of anything and
everything in D which involves sharing data across threads. The only
exception is __gshared, which is only supposed to be used for C globals
(which as I understand it, can't be shared, because that wouldn't work with
the linker), and you have to be _really_ careful whenever __gshared is used,
because the compiler assumes that it's actually thread-local, because
__gshared is not actually part of the type.

synchronized is just one way to provide a mutex for protecting shared data.
The data itself still needs to be shared and then usually has to have shared
cast away while the data is protected by the mutex that goes with
synchronized (at which point, it's up to the programmer to ensure that no
thread-local references to the data escape or exist once the mutex is
unlocked). synchronized classes (which have never been fully implemented)
are supposed to deal with automatically casting away the outer level of
shared within the member functions, but it's still the same mechanism that
you have to do now manually. If you're not using shared with synchronized,
then you're doing something seriously wrong - probably using __gshared,
which is just begging for trouble. In general, any object using synchronized
methods should be shared.

- Jonathan M Davis





More information about the Digitalmars-d mailing list