Helping with __mutable (which will be renamed to __metadata)
Radu
void at null.pt
Mon Apr 15 13:14:08 UTC 2019
On Saturday, 13 April 2019 at 03:45:35 UTC, Suleyman wrote:
> On Saturday, 13 April 2019 at 00:45:07 UTC, Andrei Alexandrescu
> wrote:
>> ...
>
> The problems you encountered are normal but the question is
> whether this feature is useful at all if the field is not
> explicitly shared? If so the a solution to the const case is to
> introduce an '@unshared' attribute instead which would protect
> against the worst cases of both being shared and being thread
> local. this attribute would disallow unsychronized read/write
> and at the same time prevent implicit conversion to 'shared'
> since it may just be thread local hence mixing it with normal
> 'shared' may not bring good results.
>
> example:
> ```
> struct S
> {
> private shared int* p; // or @unshared
>
> void inc() inout pure @system
> {
> import core.atomic;
> atomicOp!"+="(*cast(shared(int*))p, 1); // or @unshared
> }
> }
>
> void foo(ref immutable S a) pure
> {
> a.inc();
> }
>
> void foo(ref const S a) pure
> {
> a.inc();
> }
>
> int x; // thread local
> shared int y;
>
> void main()
> {
> auto i = immutable S(cast(immutable)&x);
> auto c = const S(&y);
> //auto d = const S(cast(@unshared)&x);
> foo(i);
> foo(c);
> }
> ```
I also have the impression that `shared` should be used here
instead of `__mutable`. Even in the current incarnation shared
offers some limited guarantees that atomicity is required for
writing shared values. I think people are working on making
stronger guarantees for shared.
ATM uses like the one below are a no-op, I think the reuse of
shared makes sense as it works nicely with the strong thread
safety guarantees `immutable` has, and also offers the safety net
for atomic changes. Not to mention that it is not ugly!
immutable struct Foo
{
shared(int) x;
}
More information about the Digitalmars-d
mailing list