> On Oct 7, 2016, at 9:06 PM, Gerriet M. Denkmann <g...@mdenkmann.de> wrote: > > My preferred way to count (not deprecated and fast, but, as you said, > probably not available in Swift) is: > > #import <stdatomic.h> > atomic_uint_fast64_t counter; > atomic_fetch_add_explicit( &counter, 1, memory_order_relaxed ); > > I have no idea, whether atomic_uint_fast64_t is correct (there also is > atomic_uint_least64_t — what is the difference ?) >
> I looked at <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf> (as > kindly mentioned by Alastair). > In “7.17.6 Atomic integer types” it says: “The semantics of the operations on > these types are defined in 7.17.7”. > But 7.17.7 does not mention any difference between atomic_uint_fast64_t and > atomic_uint_least64_t. These types are the atomic versions of uint_fast64_t and uint_least64_t. uint_least64_t is the smallest type that is at least 64 bits. uint_fast64_t is the fastest type that is at least 64 bits. uint64_t is exactly 64 bits. On all current architectures, uint_least64_t and uint_fast64_t and uint64_t are the same type. The differences generally appear for smaller types on older architectures. For example, uint_least8_t and uint_fast8_t might differ on a classic Cray architecture that used word-addressable memory instead of byte-addressable memory. uint_least8_t would be 8 bits but require bit-shuffling operations; uint_fast8_t would not need bit shuffling but would be a full word in size. > and what memory_order_relaxed means (Xcode suggested this to me while warning > about deprecation of OSAtomicIncrement64). Memory ordering determines how different operations are ordered with respect to each other. For example, if you were using atomic operations to implement a mutex then you would use an appropriate memory order to guarantee that all of the code protected by the lock runs inside the lock. Without memory ordering the compiler or CPU could move the protected code before the atomic lock-acquire operation completes or after the atomic lock-release operation begins, which would defeat the lock. memory_order_relaxed says that there is no additional ordering of this atomic operation with respect to anything else. This ordering is the fastest because it doesn't add any expensive memory barriers. It's fine for a simple debugging counter, but could be thread-unsafe if you had other code that did something based on the counter's value. If you are familiar with the deprecated OSAtomic functions, the difference between OSAtomicIncrement64 and OSAtomicIncrement64Barrier is memory ordering. The deprecation warning told you to use memory_order_relaxed because that is the memory ordering used by OSAtomicIncrement64. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
