Created on 2008-09-30.00:00:00 last changed 178 months ago
[Voted into WP at October, 2009 meeting.]
Proposed resolution (March, 2009):
Modify 6.9.2 [intro.multithread] paragraph 5 as follows:
All modifications to a particular atomic object M occur in some particular total order, called the modification order of M. If A and B are modifications of an atomic object M and A happens before (as defined below) B, then A shall precede B in the modification order of M, which is defined below. [Note: This states that the modification orders must respect happens before. —end note] [Note: There is a separate order for eachscalaratomic object. There is no requirement that these can be combined into a single total order for all objects. In general this will be impossible since different threads may observe modifications to different variables in inconsistent orders. —end note]
Modify 6.9.2 [intro.multithread] paragraph 7 as follows:
Certain library calls synchronize with other library calls performed by another thread. In particular, an atomic operation A that performs a release operation on an atomic object M synchronizes with an atomic operation B that performs an acquire operation on M and reads a value written by any side effect in the release sequence headed by A...
Modify 6.9.2 [intro.multithread] paragraph 12 as follows:
A visible side effect A on
ana scalar object or bit-field M with respect to a value computation B of M satisfies the conditions:
A happens before B, and
there is no other side effect X to M such that A happens before X and X happens before B.
The value of a non-atomic scalar object or bit-field M, as determined by evaluation B, shall be the value stored by the visible side effect A. [Note: If there is ambiguity about which side effect to a non-atomic object or bit-field is visible, then there is a data race, and the behavior is undefined. —end note] ...
In general, the description of the memory model is very careful to specify when the objects under discussion are atomic or non-atomic. However, there are a few cases where it could be clearer.
History | |||
---|---|---|---|
Date | User | Action | Args |
2010-03-29 00:00:00 | admin | set | status: dr -> cd2 |
2009-11-08 00:00:00 | admin | set | messages: + msg2414 |
2009-11-08 00:00:00 | admin | set | status: ready -> dr |
2009-08-03 00:00:00 | admin | set | status: review -> ready |
2009-03-23 00:00:00 | admin | set | messages: + msg1895 |
2009-03-23 00:00:00 | admin | set | status: open -> review |
2008-09-30 00:00:00 | admin | create |