Hi,
On Mon, 17 May 2010, Andrew MacLeod wrote:
> > > Well, you get the same thing you get today. Any synchronization
> > > done via a function call will tend to be correct since we never move
> > > shared memory operations across calls. Depending on your
> > > application, the types of data races the options deal with may not
> > > be an issue. Using the options will eliminate having to think
> > > whether they are issues or not at a (hopefully) small cost.
> > >
> > > Since the atomic operations are being built into the compiler, the
> > > intent is to eventually optimize and inline them for speed... and in
> > > the best case, simply result in a load or store. That's further work
> > > of course, but these options are laying some of the groundwork.
> > >
> >
> > Are you and the other proponents of that memory model seriously
> > proposing it as an alternative to explicit locking via atomic builtins
> > (that map to some form of atomic instructions)?
>
> Proposing what as an alternative?
The guarantees you seem to want to establish by the proposed memory model.
Possibly I misunderstood.
I'm not 100% sure on the guarantees you want to establish. The proposed
model seems to merge multiple concepts together, all related to
memory access ordering and atomicity, but with different scope and
difficulty to guarantee.
The mail to which I reacted seemed to me to imply that you would believe
the guarantees from the memory model alone would relieve users from
writing explicit atomic instructions for data synchronization.
If you didn't imply that, then I'm also interested to learn what other
advantages you expect to derive from the guarantees.
And third, I'm interested to learn how you intend to actually guarantee
the guarantees given by the model.
So, in short, I'd like to know
What (guarantees are established),
Why (are those sensible and useful), and
How (are those intended to be implemented)
I've tried to find this in the Wiki, but it only states some broad goals
it seems (not introduce data races). I also find the papers of Boehm
somewhat lacking when it comes to how to actually implement the whole
model on hardware, especially because he himself acknowledges the obvious
problems on real hardware, like:
* load/store reorder buffers,
* store->load forwarding,
* cache-line granularity even for strict coherency models,
* existence of weak coherency machines (have to aquire whole cache line
for exlusive write)
* general slowness of locked (or atomic) instructions compared to normal
stores/loads
* existence of store granularity on some hardware (we don't even have to
enter bit-field business, alpha e.g. has only 64 bit accesses)
But for all of these to be relevant questions we first need to know what
exactly are the intended guarantees of that model; say from the
perspective of observable behaviour from other threads.
> These optimization restrictions defined by the memory model are there to
> create predictable memory behaviour across threads.
With our without use of atomics? I.e. is the mem behaviour supposed to be
predictable also in absense of all mentions of explicitely written atomic
builtins? And you need to defined predictable. Predictable == behaves
according to rules. What are the rules?
> This is applicable when you use the atomic built-ins for locking.
> Especially in the case when the atomic operation is inlined. One goal
> is to have unoptimized program behaviour be consistent with the
> optimized version.
We have that now (because atomics are memory barriers), so that's probably
not why the model was devised.
Ciao,
Michael.
