Ticket #7804: fix_typo.patch
| File fix_typo.patch, 7.2 KB (added by , 10 years ago) |
|---|
-
boost/atomic/detail/gcc-armv6plus.hpp
57 57 // indicates the mode, so 1 is added to indicate that the destination code is Thumb. 58 58 // A temporary register is needed for the address and is passed as an argument to these 59 59 // macros. It must be one of the "low" registers accessible to Thumb code, specified 60 // us ng the "l" attribute in the asm statement.60 // using the "l" attribute in the asm statement. 61 61 // 62 62 // Architecture v7 introduces "Thumb 2", which does include (almost?) all of the ARM 63 63 // instruction set. So in v7 we don't need to change to ARM mode; we can write "universal -
boost/atomic/detail/gcc-ppc.hpp
48 48 it that values carried in registers are extended appropriately and 49 49 everything falls into place naturally). 50 50 51 The register constra nt "b" instructs gcc to use any register51 The register constraint "b" instructs gcc to use any register 52 52 except r0; this is sometimes required because the encoding for 53 53 r0 is used to signify "constant zero" in a number of instructions, 54 54 making r0 unusable in this place. For simplicity this constraint -
boost/atomic/detail/linux-arm.hpp
14 14 // Intel/Marvell XScale chips like the one in the NSLU2) have only atomic swap. 15 15 // On Linux the kernel provides some support that lets us abstract away from 16 16 // these differences: it provides emulated CAS and barrier functions at special 17 // addresses that are g araunteed not to be interrupted by the kernel. Using17 // addresses that are guaranteed not to be interrupted by the kernel. Using 18 18 // this facility is slightly slower than inline assembler would be, but much 19 19 // faster than a system call. 20 20 // -
libs/atomic/test/atomicity.cpp
21 21 // we get 0.995 probability to detect a race (if there is one). 22 22 // 23 23 // Overall this yields 0.995 * 0.995 > 0.99 confidence that the 24 // operations tru ely behave atomic if this test program does not24 // operations truly behave atomic if this test program does not 25 25 // report an error. 26 26 27 27 #include <algorithm> -
libs/atomic/doc/platform.qbk
68 68 Some amount of care must be taken as the "raw" data type 69 69 passed in from the user through [^boost::atomic<T>] 70 70 is visible here -- it thus needs to be type-punned or otherwise 71 manipulated byte-by-byte to avoid using overloaded assig ment,71 manipulated byte-by-byte to avoid using overloaded assignment, 72 72 comparison operators and copy constructors. 73 73 74 74 [endsect] … … 302 302 [section:platform_atomic_puttogether Putting it altogether] 303 303 304 304 The template specializations should be put into a header file 305 in the [^boost/atomic/detail] directory, prefer rably305 in the [^boost/atomic/detail] directory, preferably 306 306 specifying supported compiler and architecture in its name. 307 307 308 308 The file [^boost/atomic/detail/platform.hpp] must -
libs/atomic/doc/atomic.hpp
142 142 implement the operation). 143 143 144 144 The established memory order will be @c order if the operation 145 is successful. If the operation is unsucces ful, the145 is successful. If the operation is unsuccessful, the 146 146 memory order will be 147 147 148 148 - @c memory_order_relaxed if @c order is @c memory_order_acquire , … … 162 162 \param desired Desired new value 163 163 \param success_order Memory ordering constraint if operation 164 164 is successful 165 \param failure_order Memory ordering constraint if operation is unsucces ful165 \param failure_order Memory ordering constraint if operation is unsuccessful 166 166 \return @c true if value was changed 167 167 168 168 Atomically performs the following operation … … 215 215 where feasible. 216 216 217 217 The established memory order will be @c order if the operation 218 is successful. If the operation is unsucces ful, the218 is successful. If the operation is unsuccessful, the 219 219 memory order will be 220 220 221 221 - @c memory_order_relaxed if @c order is @c memory_order_acquire , … … 235 235 \param desired Desired new value 236 236 \param success_order Memory ordering constraint if operation 237 237 is successful 238 \param failure_order Memory ordering constraint if operation is unsucces ful238 \param failure_order Memory ordering constraint if operation is unsuccessful 239 239 \return @c true if value was changed 240 240 241 241 Atomically performs the following operation -
libs/atomic/doc/atomic.qbk
115 115 116 116 [section:mutex Enforcing ['happens-before] through mutual exclusion] 117 117 118 As an introduct ury example to understand how arguing using118 As an introductory example to understand how arguing using 119 119 ['happens-before] works, consider two threads synchronizing 120 120 using a common mutex: 121 121 … … 142 142 at [^m.lock()]. If this is be thread1, then as a consequence, 143 143 thread2 cannot succeed at [^m.lock()] before thread1 has executed 144 144 [^m.unlock()], consequently A ['happens-before] B in this case. 145 By symmetry, if thread2 suc eeds at [^m.unlock()] first, we can145 By symmetry, if thread2 succeeds at [^m.unlock()] first, we can 146 146 conclude B ['happens-before] A. 147 147 148 148 Since this already exhausts all options, we can conclude that … … 628 628 from C++11 as faithfully as possible, there are a few 629 629 limitations that cannot be lifted without compiler support: 630 630 631 * [*Using non-POD-classes as template param ater to `atomic<T>` results631 * [*Using non-POD-classes as template parameter to `atomic<T>` results 632 632 in undefined behavior]: This means that any class containing a 633 633 constructor, destructor, virtual methods or access control 634 634 specifications is not a valid argument in C++98. C++11 relaxes … … 666 666 of [*Boost.Atomic] compiles and has correct value semantics. 667 667 * [*native_api.cpp] verifies that all atomic operations have correct 668 668 value semantics (e.g. "fetch_add" really adds the desired value, 669 retur ing the previous). It is a rough "smoke-test" to help weed669 returning the previous). It is a rough "smoke-test" to help weed 670 670 out the most obvious mistakes (for example with overflow, 671 671 signed/unsigned extension, ...). 672 672 * [*lockfree.cpp] verifies that the [*BOOST_ATOMIC_*_LOCKFREE] macros
