If you could make any changes to D, what would they look like?
nise at nise.com
Mon Oct 25 18:04:19 UTC 2021
On Monday, 25 October 2021 at 17:17:14 UTC, Ola Fosheim Grøstad
> Shared is actually one of the more promising aspects of D where
> it could stand out, but you need to be very pedantic when
> designing it (theoretical) and make sure that the resulting
> type system is sound. Meaning, you cannot allow "convenient
> hacks" and "pragmatic exceptions". It remains to be seen if D
> can adopt enough strong guarantees (be more principled) to make
> "shared" useful.
> I think it is possible to define shared in a potent manner,
> that gives optimization opportunities, but I am not sure if the
> majority of D users would embrace it.
>> It's convenient for quick-n-dirty concurrent OO code where
>> performance isn't critical. But if you want more modern
>> concurrent techniques / high performance, yeah, it's not of
>> much use. It's arguably dated technology.
> Synchronized has runtime debt. That is a higher-level language
> design choice and not really a system level design choice. You
> could redefine the semantics so you don't have to account for
> it in the runtime, I think.
There are a few rules I've discovered with concurrent programming.
Always take the lock, don't dwell into atomic
operations/structures too much. 99% of the cases should be
handled by traditional mutex/semaphores and possible language
layers above that.
Synchronized classes are good because the lock is implicit.
However, it might be inefficient if you use several methods after
each other which means several lock/unlock (Acquire/Release or
whatever you name it) after each other.
One of the best designs in Rust was to combine the borrowing with
acquiring the lock. Then you can borrow/lock on a structure do
all the operations you want as in normal single threaded
programming and it will be released automatically when the borrow
goes out of scope. This is is a genius design and I'm not sure
how to pry it into D.
Then we have the shared structs/classes in D where all basic
types are forced to be atomic, which is totally insane. Lock free
algorithms often consist of both normal and atomic variables.
Also if you have several atomic variables, the operations on them
together often introduce race conditions and your structure is
not thread safe at all. When you are in lock free territory you
are on your own and shared should only mean, this can be safely
used from several threads at the same time. Compiler should do
nothing more. Then we can also combine lock free structures with
locked structures and where these are appropriate depends on the
use case. Basically, the compiler should stay away from any
More information about the Digitalmars-d