Why D is not popular enough?

[ag0aep6g via Digitalmars-d]

On 08/12/2016 08:04 PM, Andrei Alexandrescu wrote:
> On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:
[...]
>> shared int x;
>> ++x; // error, must use atomicOp.
>> x = x + 1; // OK(!)
>
> How is this broken and how should it behave? -- Andrei

I may be responsible for some confusion here, including my own.

Disclaimer: I'm far from being an expert on thread-safety. I may have 
misunderstandings about fundamentals.

Recently, I made a thread titled "implicit conversions to/from shared":
http://forum.dlang.org/post/nlth0p$1l7g$1@digitalmars.com

Before starting that thread, and before messing with atomicOp, I had 
assumed that D enforces atomic reads/writes on shared types. Then I 
noticed that I can read/write shared types that are too large for atomic 
ops.

Example:

----
alias T = ubyte[1000];

enum T a = 1;
enum T b = 2;

shared T x = a;

import core.thread: Thread;

void write()
{
     bool flip = false;
     foreach (i; 0 .. 1_000_000)
     {
         if (flip) x = a; else x = b; // non-atomic write
         flip = !flip;
     }
}

void main()
{
     auto t = new Thread(&write);
     t.start();
     foreach (i; 0 .. 1_000_000)
     {
         T r = x; // non-atomic read
         assert(r == a || r == b); // fails
     }
     t.join();
}
----

I tested a bunch of stuff, and I remember having a test case that failed 
with a primitive type like int, but I can't find or recreate it now, and 
a little googling suggests that reading/writing should be atomic for 
primitive types (on X86 with various restrictions). So I probably just 
had an error in that test.

But the above test case stands, and it also fails with -m32 and ulong:

----
alias T = ulong;

enum T a = 0x01_01_01_01__01_01_01_01;
enum T b = 0x02_02_02_02__02_02_02_02;

/* rest as above */
----

So, `shared int x; x = x + 1;` is ok, as far as I see now. But with 
other types, unsafe reads/writes are generated.