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