[Omp] A question about OpenMP 2.5

[Bronis R. de Supinski]

Grant:

Re:
> Yes, I understand the programming problem.  Would "word-size" of the
> machine as the smallest guaranteed atomic memory access be acceptable?
> I don't know of any machines that don't implement that.  That might be
> much easier to get through the committee than one fixed size, especially
> since there are lots of HW vendors on the Language committee that
> already support OpenMP.

That would be fine if there is a guarantee that ints and floats
will always be at least "word-size". I think that is not an
unreasonable restriction (and the compiler can enforce it).

> I think if you try to propose atomicity at the level of single bytes,
> you'll be hard pressed to get it through the committee.

I said that to be intentionally controversial. I understand why
vendors would object to byte level atomicity.

Bronis

> - Grant
>
> -----Original Message-----
> From: Bronis R. de Supinski [mailto:bronis at llnl.gov]
> Sent: Wednesday, March 21, 2007 1:44 PM
> To: Haab, Grant
> Cc: Jakub Jelinek; omp at openmp.org
> Subject: RE: [Omp] A question about OpenMP 2.5
>
>
> Grant:
>
> Re:
> > I think it is unreasonable for the OpenMP specification to enforce an
> > atomicity constraint on the entire application.  What if some called
> > modules weren't compiled with the OpenMP compiler?  How do we insert
> > atomic instructions for all accesses in those? What about
> > system/language libraries?  Where does this stop?
> >
> > If you need enforced atomicity for data access smaller than the target
> > machine word size, then either code it with conditional atomic
> > directives/pragmas (for that machine) or complain to your hardware
> > manufacturer.
>
> Where does it end? Can I assume arrays of ints will work
> correctly in parallel for regions? floats? doubles? Anything?
> Do I have to write all code with conditional critical sections
> or atomic directives in order to achieve portability?
>
> As I said, I am sympathetic but only so far. I don't see how
> we can claim OpenMP does anything if I can't assume disjoint
> accesses to an array of doubles or floats or ints can proceed
> safely in parallel.
>
> If the hardware won't support it, then don't offer OpenMP. When
> building DSM solutions, you can enforce it...
>
> Bronis
>
>
>
> > - Grant
> >
> > -----Original Message-----
> > From: omp-bounces at openmp.org [mailto:omp-bounces at openmp.org] On Behalf
> > Of Bronis R. de Supinski
> > Sent: Wednesday, March 21, 2007 10:33 AM
> > To: Jakub Jelinek
> > Cc: omp at openmp.org
> > Subject: Re: [Omp] A question about OpenMP 2.5
> >
> >
> > Jakub:
> >
> > Re:
> > > On Wed, Mar 21, 2007 at 05:00:29AM -0700, Bronis R. de Supinski
> wrote:
> > > > Note that it is not clear where to define the hardware
> > > > aromicity level, which is why the specification has tried
> > > > to avoid doing so. I could easily argue that the right
> > > > level of write atomicity for a DSM implementation is at
> > > > the page granularity. While I don't think anyone would
> > > > accept that, it is very unclear where we stop. If Brad's
> > > > example used a char array, does it work? I would hope so...
> > >
> > > Not everywhere.  E.g. older Alpha CPUs (without BWX extension, like
> > > ev4, ev45 or ev5) couldn't write 8 and 16-bit quantities atomically,
> > only
> > > 32-bit and above, so for 8 and 16-bit accesses it would need to read
> > > old 32-bit word, update the byte in question in it and store it
> again.
> >
> > Yes, this does not surprise me. My point was a position
> > on how we need to modify the spec. I think Brad's question
> > demonstrates that we will need to specify SOME minimum
> > level of atomicity. I was staking a position of byte level
> > with char; if the hardware doesn't support it then the
> > OpenMP implementation would need to include sufficient
> > synchronization to guarantee it. I understand this might
> > entail undue hardship and I could be convinced that four
> > bytes is the right level (more than that seems unreasonable).
> >
> > Bronis
> > _______________________________________________
> > Omp mailing list
> > Omp at openmp.org
> > http://openmp.org/mailman/listinfo/omp
> >
> >
>
>