On Tuesday, 12 July 2016 at 16:14:58 UTC, ag0aep6g wrote:
The deprecation of ++ shows that (currently) shared's purpose
is not only to differentiate between shared and unshared data.
Feel free to submit a corresponding spec change PR stating that
you want to extend shared's purpose to solve as
On Tuesday, 12 July 2016 at 15:46:52 UTC, Kagamin wrote:
shared only differentiates between shared and unshared data.
Teaching people to write legit concurrent code is a different
task. Increment of a shared variable doesn't have a compelling
use case so whatever happens to it is not important,
On Tuesday, 12 July 2016 at 14:38:27 UTC, ag0aep6g wrote:
I'm not sure what you're saying here. Should unsafe reading and
writing of shared types simply be allowed and have the common
syntax (as it is now), and the programmer should make sure that
things are set up correctly?
That's a reasona
On 07/12/2016 03:51 PM, Kagamin wrote:
It's strange if you want to expose a bare volatile variable to the rest
of the world and expect the world to cope with concurrency on every access.
I'm not sure what you're saying here. Should unsafe reading and writing
of shared types simply be allowed a
On Tuesday, 12 July 2016 at 12:47:05 UTC, ag0aep6g wrote:
In contrast, unsafe reading/writing of shared data that looks
like just another assignment is similarly problematic and
harder to spot.
It's strange if you want to expose a bare volatile variable to
the rest of the world and expect the
On 07/12/2016 02:28 PM, Kagamin wrote:
On Monday, 11 July 2016 at 13:54:49 UTC, ag0aep6g wrote:
Also currently atomicLoad doesn't provide functionality
equivalent to raw load.
Is a "raw load" just a non-atomic load, or is it something special?
What's the relevance of atomicLoad's capabilities?
On 07/12/2016 02:26 PM, Kagamin wrote:
On Monday, 11 July 2016 at 13:54:49 UTC, ag0aep6g wrote:
If I got that right: Sure. But the compiler can't know if a shared
variable is volatile or not, so it has to assume that it is. If the
programmer knows that it's not volatile, they can cast shared awa
On Monday, 11 July 2016 at 13:54:49 UTC, ag0aep6g wrote:
Also currently atomicLoad doesn't provide functionality
equivalent to raw load.
Is a "raw load" just a non-atomic load, or is it something
special?
What's the relevance of atomicLoad's capabilities?
You suggested to use atomicLoad to
On Monday, 11 July 2016 at 13:54:49 UTC, ag0aep6g wrote:
If I got that right: Sure. But the compiler can't know if a
shared variable is volatile or not, so it has to assume that it
is. If the programmer knows that it's not volatile, they can
cast shared away and use a normal load.
If you cast
On 07/11/2016 03:23 PM, ag0aep6g wrote:
I think I would prefer if the compiler would generate atomic operations,
Backpedaling on that one.
With automatic atomic loads and stores, one could accidentally write this:
shared int x;
x = x + 1; /* atomic load + atomic != atomic increment */
On 07/11/2016 03:31 PM, Kagamin wrote:
Atomic loads are only needed for volatile variables, not for all kinds
of shared data.
Volatile just means that another thread can mess with the data, right?
So shared data that's not being written to from elsewhere isn't
volatile, and one doesn't need a
On Monday, 11 July 2016 at 05:26:42 UTC, ag0aep6g wrote:
Simply disallow reading and writing shared then, forcing
something more explicit like atomicLoad/atomicStore?
That would be better than the current state, but it would make
shared even more unwieldy.
Atomic loads are only needed for vo
On 07/11/2016 02:54 PM, Steven Schveighoffer wrote:
I think you misunderstand the problem here.
Yes.
Conversion means changing
the type.
Once you have loaded the shared data into a register, or whatever, it's
no longer shared, it's local. Writing it out to another place doesn't
change anythi
On 7/10/16 9:02 AM, ag0aep6g wrote:
While messing with atomicLoad [1], I noticed that dmd lets me implicitly
convert values to/from shared without restrictions. It's in the spec
[2]. This seems bad to me.
I think you misunderstand the problem here. Conversion means changing
the type.
Once yo
On 07/11/2016 07:26 AM, ag0aep6g wrote:
On 07/11/2016 01:52 AM, Alex Parrill wrote:
[...]
I don't think there is an issue with converting unshared reference types
to shared (ex. ref T -> ref shared(T) or T* -> shared(T)*); worst you
get is some extra synchronization.
shared(T)* is not shared
On 07/11/2016 01:52 AM, Alex Parrill wrote:
Atomic loading and storing, from what I understand, is usually limited
to about a word on most architectures. I don't think it would be good to
implicitly define assignment and referencing as atomic operations, since
it would be limited. IMO concurrent
On Sunday, 10 July 2016 at 13:02:17 UTC, ag0aep6g wrote:
While messing with atomicLoad [1], I noticed that dmd lets me
implicitly convert values to/from shared without restrictions.
It's in the spec [2]. This seems bad to me.
[...]
Atomic loading and storing, from what I understand, is usual
While messing with atomicLoad [1], I noticed that dmd lets me implicitly
convert values to/from shared without restrictions. It's in the spec
[2]. This seems bad to me.
Here's how I understand shared. If anything's wrong, I'd appreciate if
someone would educate me.
Shared is there to prevent
18 matches
Mail list logo
