[Omp] A question about OpenMP 2.5

[Hoeflinger, Jay P]

I just want to clear up one mis-conception.  Not all DSM systems have a
granularity of one page.  For instance, Cluster OpenMP has a granularity
of 4 bytes.

Jay

-----Original Message-----
From: omp-bounces at openmp.org [mailto:omp-bounces at openmp.org] On Behalf
Of Haab, Grant
Sent: Wednesday, March 21, 2007 2:07 PM
To: Bronis R. de Supinski
Cc: omp at openmp.org
Subject: Re: [Omp] A question about OpenMP 2.5

Bronis,

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.

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.

- 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
>
>
_______________________________________________
Omp mailing list
Omp at openmp.org
http://openmp.org/mailman/listinfo/omp