shared - i need it to be useful
Atila Neves
atila.neves at gmail.com
Thu Oct 18 17:17:37 UTC 2018
On Monday, 15 October 2018 at 18:46:45 UTC, Manu wrote:
> 1. shared should behave exactly like const, except in addition
> to inhibiting write access, it also inhibits read access.
How is this significantly different from now?
-----------------
shared int i;
++i;
Error: read-modify-write operations are not allowed for shared
variables. Use core.atomic.atomicOp!"+="(i, 1) instead.
-----------------
There's not much one can do to modify a shared value as it is.
> Current situation where you can arbitrarily access shared
> members
> undermines any value it has.
Unless I'm missing something, I can't arbitrarily do anything
with shared members right now.
> Shared must assure you don't access
> members unsafely, and the only way to do that with respect to
> data
> members, is to inhibit access completely.
Or use atomic operations.
> Assuming this world... how do you use shared?
https://github.com/atilaneves/fearless
or
https://dlang.org/phobos/core_atomic.html
> From there, it opens up another critical opportunity; T* ->
> shared(T)*
> promotion.
I don't think that works. See below.
> If you write a lock-free queue for instance, and all the
> methods are
> `shared` (ie, threadsafe), then under the current rules, you
> can't
> interact with the object when it's not shared, and that's fairly
> useless.
Not really:
-----------
struct FancyQueue(E) {
// ...
void pushBack(this T)(E element) {
static if(is(T == shared)) {
// lock mutex or whatever is needed
auto safeThis = () @trusted { return cast(FancyQueue)
this; }();
} else {
// no need to lock anything
alias safeThis = this;
}
// profit
}
}
-----------
Usable if shared or not.
> Assuming the rules above: "can't read or write to members", and
> the understanding that `shared` methods are expected to have
> threadsafe implementations (because that's the whole point),
> what are the risks from allowing T* -> shared(T)* conversion?
int i;
tid.send(&i);
++i; // oops, data race
> All the risks that I think have been identified previously
> assume that you can arbitrarily modify the data.
Do you have any examples of arbitrarily modifying shared data? I
can't think of any.
> That's insanity... assume we fix that... I think the promotion
> actually becomes safe now...?
I don't think so, no.
More information about the Digitalmars-d
mailing list