[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