[Omp] A question about OpenMP 2.5

[Bronis R. de Supinski]

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
>
>