Something needs to happen with shared, and soon.
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Thu Nov 15 17:54:11 PST 2012
On 11/15/12 3:05 PM, David Nadlinger wrote:
> On Thursday, 15 November 2012 at 22:57:54 UTC, Andrei Alexandrescu wrote:
>> On 11/15/12 1:29 PM, David Nadlinger wrote:
>>> On Wednesday, 14 November 2012 at 17:54:16 UTC, Andrei Alexandrescu
>>> wrote:
>>>> That is correct. My point is that compiler implementers would follow
>>>> some specification. That specification would contain informationt hat
>>>> atomicLoad and atomicStore must have special properties that put them
>>>> apart from any other functions.
>>>
>>> What are these special properties? Sorry, it seems like we are talking
>>> past each other…
>>
>> For example you can't hoist a memory operation before a shared load or
>> after a shared store.
>
> Well, to be picky, that depends on what kind of memory operation you
> mean – moving non-volatile loads/stores across volatile ones is
> typically considered acceptable.
In D that's fine (as long as in-thread SC is respected) because
non-shared vars are guaranteed to be thread-local.
> But still, you can't move memory operations across any other arbitrary
> function call either (unless you can prove it is safe by inspecting the
> callee's body, obviously), so I don't see where atomicLoad/atomicStore
> would be special here.
It is special because e.g. on x86 the function is often a simple
unprotected load or store. So after the inliner has at it, there's
nothing to stay in the way of reordering. The point is the compiler must
understand the semantics of acquire and release.
Andrei
More information about the Digitalmars-d
mailing list