← Back to branch summary

~ubuntu-branches/ubuntu/lucid/libatomic-ops/lucid

« back to all changes in this revision

Viewing changes to doc/README.txt

  • Committer: Bazaar Package Importer
  • Author(s): Ian Wienand
  • Date: 2008-08-19 14:25:24 UTC
  • mfrom: (0.1.3 upstream)
  • Revision ID: james.westby@ubuntu.com-20080819142524-2767wsbmg7isqv23
Tags: 1.2+cvs20080819-1
http://bugs.debian.org/495211
* Update from upstream CVS
* Closes: #495211 -- patch taken upstream, thanks Thiemo!

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/README.txt
59
59
are:
60
60
 
61
61
- AO_test_and_set operates on AO_TS_t, which is whatever size the hardware
62
 
supports with good performance.  In some cases this is the length of a cache line.
63
 
In some cases it is a byte.  In many cases it is equivalent to AO_t.
 
62
supports with good performance.  In some cases this is the length of a cache
 
63
line.  In some cases it is a byte.  In many cases it is equivalent to AO_t.
64
64
 
65
65
- A few operations are implemented on smaller or larger size integers.
66
66
Such operations are indicated by the appropriate prefix:
80
80
 
81
81
void nop()
82
82
        No atomic operation.  The barrier may still be useful.
83
 
AO_t load(volatile AO_t * addr)
 
83
AO_t load(const volatile AO_t * addr)
84
84
        Atomic load of *addr.
85
85
void store(volatile AO_t * addr, AO_t new_val)
86
86
        Atomically store new_val to *addr.
154
154
_write: Earlier writes become visible before writes during or after
155
155
        the atomic operation.  Rarely useful for clients?
156
156
_full: Ordered with respect to both earlier and later memops.
 
157
       AO_store_full or AO_nop_full are the normal ways to force a store
 
158
       to be ordered with respect to a later load.
157
159
_release_write: Ordered with respect to earlier writes.  This is
158
160
                normally implemented as either a _write or _release
159
161
                barrier.
162
164
               a pointer read, which is later dereferenced to read a
163
165
               second value, with the expectation that the second
164
166
               read is ordered after the first one.  On most architectures,
165
 
               this is equivalent to no barrier.
 
167
               this is equivalent to no barrier.  (This is very
 
168
               hard to define precisely.  It should probably be avoided.
 
169
               A major problem is that optimizers tend to try to
 
170
               eliminate dependencies from the generated code, since
 
171
               dependencies force the hardware to execute the code
 
172
               serially.)
166
173
_release_read: Ordered with respect to earlier reads.  Useful for
167
174
               implementing read locks.  Can be implemented as _release,
168
175
               but not as _read, since _read groups the current operation
194
201
 
195
202
Future directions:
196
203
 
197
 
We expect the list of memory barrier types to remain more or less fixed.
198
 
However, it is likely that the list of underlying atomic operations will
199
 
grow.  It would also be useful to support double-wide and narrower operations
200
 
when available.
 
204
It currently appears that something roughly analogous to this is very likely
 
205
to become part of the C++0x standard.  That effort has pointed out a number
 
206
of issues that we expect to address there.  Since some of the solutions
 
207
really require compiler support, they may not be completely addressed here.
 
208
 
 
209
Known issues include:
 
210
 
 
211
We should be more precise in defining the semantics of the ordering
 
212
constraints, and if and how we can guarantee sequential consistency.
 
213
 
 
214
Dd_acquire_read is very hard or impossible to define in a way that cannot
 
215
be invalidated by reasonably standard compiler transformations.
 
216
 
 
217
There is probably no good reason to provide operations on standard
 
218
integer types, since those may have the wrong alignment constraints.
 
219
 
201
220
 
202
221
Example:
203
222