[Omp] Shared Variable Problem

[Sven Karlsson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

Meadows, Lawrence F wrote:
> What I'm getting at is that it would be nice to have some sort
> of least-common-denominator hardware atomicity so that OpenMP
> programs on most platforms could roll their own synchronization.

This is something I would never want to see in OpenMP. I think OpenMP is
definitely going in the wrong direction if requirements on hardware is
added.

> Or you could take my latest stance which is that you shouldn't
> do that anyway and flush is an abomination.

This is an opinion that I now fully agree with. I never liked explicit
flushes. They are difficult to support efficiently on clusters. They are
also difficult to understand unless you know a lot about computer
architecture and memory consistency models. In fact, memory consistency
models are unfortunately sometimes misunderstood by people that claim
they know them. I can, without shame, confess that I can not explain
each and every existing model without first consulting the relevant
papers or documentation. There are simply too many variations. To make
things even worse, some (processor) implementations are not fully or
clearly documented. This is, in particular, true for some multiprocessor
implementations. Over the last few years I have actually started to
really dislike explicit flushes. How do you explain to a programmers why
their programs work on one machine but not another (and how they should
write their programs) without giving them a crash course on computer
architecture, formal methods and memory consistency?

My opinion is that OpenMP constructs should be defined so that the
programmer should not have to worry about memory consistency issues.
Parallel programming is hard enough even without such issues.

I also think that programmers should never be forced or even feel the
need to implement their own synchronization primitives. The focus should
rather be to define and propose new safe synchronization constructs if
the existing are not enough.

Transactional memory has currently a lot of momentum. I am not yet
convinced that transactional memory is the "silver bullet". There seem
to be plenty of cases that are not very well understood yet. For
example, how should nested transactions be handled? I am not sure it is
a good idea to include transactional semantics into OpenMP before the
research area has matured.

Best regards
 Sven
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE0FqqLpCgk7P1PqwRAiy1AJ9W+/zJh4N/GfyrA4Qt6hL5ET4VrgCeJ2OX
f7kl4mUFZ3+HavvKF16EwTs=
=uUQR
-----END PGP SIGNATURE-----