[petsc-dev] de-global variablelizing PETSc
Jed Brown
jedbrown at mcs.anl.gov
Sun Nov 10 19:30:58 CST 2013
Barry Smith <bsmith at mcs.anl.gov> writes:
> I assume this depends on what configure finds?
Yeah, we can test for a bunch of them, but the interfaces are not
equivalent. The typical inline assembly approach has (memory
barrier-free) atomic operations and memory barriers while C11 has
acquire/release semantics. There can be a (minor) loss of efficiency
when implementing one in terms of the other, depending on the memory
model of the hardware. OpenMP's memory model has changed over the years
(e.g., http://www.nic.uoregon.edu/iwomp2005/Papers/f29.pdf has a
nonsensical interpretation of the volatile keyword, which was later
removed) and omp flush is a blunt instrument.
If all we need are simple locks, then this doesn't matter, but
an asynchronous threadcomm needs sharper tools.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131110/3154b05a/attachment.sig>
More information about the petsc-dev
mailing list