Re: How to count Atoms

[Greg Parker]

> On Oct 7, 2016, at 9:06 PM, Gerriet M. Denkmann  wrote:
> 
> My preferred way to count (not deprecated and fast, but, as you said, 
> probably not available in Swift) is:
> 
> #import   
> atomic_uint_fast64_t counter;
> atomic_fetch_add_explicit( , 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  (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  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

Re: How to count Atoms

[Jens Alfke]

> On Oct 7, 2016, at 10:05 AM, Quincey Morris 
>  wrote:
> 
> Surely “anyone reading the code” is going to recognize “dispatch_semaphore” 
> as something to do with a semaphore, including people from other platforms?

You’re right; I was [mis]remembering a classic semaphore as being a simple 
mutex lock, but a look at Wikipedia corrected me: it has the counting semantics 
that dispatch_semaphore does.

I still say it’s massive overkill to use it in a simple atomic increment task, 
as Gerriet’s performance figures show. You might still say that 80x faster 
isn’t important, but that depends on what you’re doing. I often work on highly 
performance-sensitive code, as Gerriet also does apparently. 

—Jens
___

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

Re: How to count Atoms

[Gerriet M. Denkmann]

> On 8 Oct 2016, at 11:22, Quincey Morris  
> wrote:
> 
> On Oct 7, 2016, at 21:06 , Gerriet M. Denkmann  wrote:
>> 
>> But, alas, it is also much slower: overhead almost 40 sec (whereas my 
>> admittedly rather hackish way took less then half a second).
> 
> That may indicate a lot of contention — e.g. you were running multiple copies 
> of that loop in different threads, and each loop was doing an increment every 
> iteration. I’d actually try doing it this way:
> 
>>  //  One-time initialization, globally
>> 
>>  dsema = dispatch_semaphore_create (1);
>> 
>>  NSUInteger counter = 0;
>>  
>> 
>>  //  Per-thread code, locally
>> 
>>  NSUInteger perThreadCounter = 0;
>> 
>>  for …
>>  {
>>  …
>>  perThreadCounter++;
>>  }
>> 
>>  dispatch_semaphore_wait (dsema, );
>>  counter += perThreadCounter;
>>  dispatch_semaphore_signal (dsema);
> 
> That should diminish the overhead to, effectively, zero.

Well, it diminishes the overhead from about 40 sec to less than 60 msec - a 
huge improvement indeed.
But, using the same perThreadCounter, atomic_fetch_add_explicit has an overhead 
of less than 2 msec.

I really should have thought of an perThreadCounter myself - it is obviously so 
much better.
Thanks for pointing me in the right direction!

Kind regards,

Gerriet.


___

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

Re: How to count Atoms

[Quincey Morris]

On Oct 7, 2016, at 21:06 , Gerriet M. Denkmann  wrote:
> 
> But, alas, it is also much slower: overhead almost 40 sec (whereas my 
> admittedly rather hackish way took less then half a second).

That may indicate a lot of contention — e.g. you were running multiple copies 
of that loop in different threads, and each loop was doing an increment every 
iteration. I’d actually try doing it this way:

>   //  One-time initialization, globally
> 
>   dsema = dispatch_semaphore_create (1);
> 
>   NSUInteger counter = 0;
>   
> 
>   //  Per-thread code, locally
> 
>   NSUInteger perThreadCounter = 0;
> 
>   for …
>   {
>   …
>   perThreadCounter++;
>   }
> 
>   dispatch_semaphore_wait (dsema, );
>   counter += perThreadCounter;
>   dispatch_semaphore_signal (dsema);

That should diminish the overhead to, effectively, zero.

But this is a bit academic, if you have a non-deprecated method of atomic 
incrementing available. This is about what you might do for a more complicated 
calculation that is not inherently atomic.



___

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

Re: How to count Atoms

[Gerriet M. Denkmann]

> On 8 Oct 2016, at 05:01, Quincey Morris  
> wrote:
> 
> On Oct 7, 2016, at 07:49 , Gerriet M. Denkmann  wrote:
>> 
>> Is there a better way than this:
>> dsema = dispatch_semaphore_create( 0 );   
>> 
>> some loop to be counted
>> {
>>  dispatch_semaphore_signal(dsema); 
>>  ….
>> }
>> 
>> NSUInteger counter = 0;
>> for(;;)
>> {
>>  long a = dispatch_semaphore_wait(dsema, DISPATCH_TIME_NOW);
>>  if ( a != 0 ) break;
>>  counter++;
>> };
> 
> Er, I didn’t pay enough attention to this when you posted. No, this isn’t the 
> correct approach. You’re supposed to be using the semaphore as a lock. In 
> theory, you’d do it like this:
> 
>>  dsema = dispatch_semaphore_create (1);
>> 
>>  NSUInteger counter = 0;
>> 
>>  for …
>>  {
>>  …
>>  dispatch_semaphore_wait (dsema, );
>>  counter++;
>>  dispatch_semaphore_signal (dsema);
>>  }
> 
> That is, the semaphore controls access to a pool of 1 resources (the resource 
> being permission to increment the counter), and you wait on the resource to 
> become available (“lock”), increment the counter, then release the resource 
> (“unlock”).

This looks much better. 
But, alas, it is also much slower: overhead almost 40 sec (whereas my 
admittedly rather hackish way took less then half a second).

B.t.w.: I also tried NSLock - it is even slower (but not much) than 
@synchronized.

My preferred way to count (not deprecated and fast, but, as you said, probably 
not available in Swift) is:

#import 
atomic_uint_fast64_t counter;
atomic_fetch_add_explicit( , 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 ?)
and what memory_order_relaxed means (Xcode suggested this to me while warning 
about deprecation of OSAtomicIncrement64).

I looked at  (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.


Kind regards,

Gerriet.


___

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

Re: How to count Atoms

[Quincey Morris]

On Oct 7, 2016, at 15:37 , Dave Fernandes  wrote:
> 
> But I don’t see how incrementing it after creating it is any different from 
> creating it with a non-zero count. Either way, if you have resources 
> available, the count will be non-zero, and you will crash if you try to 
> deallocate.

The difference is internal: the semaphore remembers what its initial count was, 
and the semaphore requires the count to be at least as large at the time of 
deallocation. It’s supposedly a sanity check. There’s no *functional* reason 
for it.

The rationale is that a lower count indicates that you’ve “leaked” resources: 
if the resources had all been “released” back into the pool the count would 
have returned to its initial value. The situation I encountered was with Audio 
Queue Services, where I was using a semaphore to control access to a pool of 
buffers. Under some error conditions, I abandoned playback and disposed of the 
audio queue, but the queue then did not call the delegate method that normally 
informs the client of available buffers (though the buffers weren’t actually 
leaked, just silently disposed of). The app then crashed when disposing of the 
semaphore.

Note that there’s no check of the opposite condition: if the count at disposal 
is greater than the initial count, there’s no crash.

One workaround would be to force-increment the semaphore before disposing of 
it, if necessary, but it’s slightly easier to create the semaphore with a zero 
count and pre-increment it to the starting resource count.

___

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

Re: How to count Atoms

[Dave Fernandes]

> 
> In practice, you’d actually initialize the semaphore like this:
> 
>>  dsema = dispatch_semaphore_create (0); // start with a zero count
>>  dispatch_semaphore_signal (dsema); // increment to the number of 
>> resources in the pool.
> 
> That’s because if you create the semaphore with a non-zero count, then later 
> try to release the semaphore object when its count is something different 
> (which can happen if you have a more complex loop that you break out of), 
> your app will crash. The API design assumption is that if you didn’t free all 
> the original resources, your app has a bug (which I happen to think is bogus 
> reasoning, but anyway…).

Wow, I’ve never come across that issue. But I don’t see how incrementing it 
after creating it is any different from creating it with a non-zero count. 
Either way, if you have resources available, the count will be non-zero, and 
you will crash if you try to deallocate. But I’m somewhat sure I’ve never seen 
a crash like that. Maybe I was just lucky?
___

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

Re: How to count Atoms

[Quincey Morris]

On Oct 7, 2016, at 07:49 , Gerriet M. Denkmann  wrote:
> 
> Is there a better way than this:
> dsema = dispatch_semaphore_create( 0 );
> 
> some loop to be counted
> {
>   dispatch_semaphore_signal(dsema); 
>   ….
> }
> 
> NSUInteger counter = 0;
> for(;;)
> {
>   long a = dispatch_semaphore_wait(dsema, DISPATCH_TIME_NOW);
>   if ( a != 0 ) break;
>   counter++;
> };

Er, I didn’t pay enough attention to this when you posted. No, this isn’t the 
correct approach. You’re supposed to be using the semaphore as a lock. In 
theory, you’d do it like this:

>   dsema = dispatch_semaphore_create (1);
> 
>   NSUInteger counter = 0;
> 
>   for …
>   {
>   …
>   dispatch_semaphore_wait (dsema, );
>   counter++;
>   dispatch_semaphore_signal (dsema);
>   }

That is, the semaphore controls access to a pool of 1 resources (the resource 
being permission to increment the counter), and you wait on the resource to 
become available (“lock”), increment the counter, then release the resource 
(“unlock”).

In practice, you’d actually initialize the semaphore like this:

>   dsema = dispatch_semaphore_create (0); // start with a zero count
>   dispatch_semaphore_signal (dsema); // increment to the number of 
> resources in the pool.

That’s because if you create the semaphore with a non-zero count, then later 
try to release the semaphore object when its count is something different 
(which can happen if you have a more complex loop that you break out of), your 
app will crash. The API design assumption is that if you didn’t free all the 
original resources, your app has a bug (which I happen to think is bogus 
reasoning, but anyway…).


___

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

Re: How to count Atoms

[Kyle Sluder]

On Fri, Oct 7, 2016, at 11:24 AM, Jens Alfke wrote:
> 
> > On Oct 7, 2016, at 1:14 AM, Quincey Morris 
> >  wrote:
> > 
> > One straightforward way is to use dispatch_semaphore. IIRC it’s lightweight 
> > unless it blocks (that is, unless its count is zero when you wait), so it’s 
> > good for this situation where actual contention is rare (assuming actual 
> > contention is rare).
> 
> IMO dispatch_semaphore is overkill for this; it’s not just an atomic
> counter, it’s also got blocking behaviors for use in e.g. managing a pool
> of resources. I’ll bet that most Mac/iOS programmers don’t know about it,
> let alone people coming from other platforms.
> 
> The simplest solution is just to use an atomic operation. Even if there
> isn’t a standard atomic API in C (as there is in C++), anyone reading the
> code is probably going to understand what OSAtomicIncrement32() does just
> from its name.

OSAtomic.h (except for OSAtomicQueue) is deprecated. Don’t use
OSAtomicIncrement32 in new code.

--Kyle Sluder

> 
> —Jens

___

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

Re: How to count Atoms

[Quincey Morris]

On Oct 7, 2016, at 09:24 , Jens Alfke  wrote:
> 
> IMO dispatch_semaphore is overkill for this; it’s not just an atomic counter, 
> it’s also got blocking behaviors for use in e.g. managing a pool of resources.

I wasn’t suggesting using dispatch_semaphore itself as the atomic counter, but 
rather as an atomicity strategy for a separate increment calculation. So, yes, 
it’s overkill compared to a true atomic increment operation, but (being pretty 
much just an increment/decrement each time it’s hit) it’s pretty cheap as 
overhead goes (unlike @synchronized).

> I’ll bet that most Mac/iOS programmers don’t know about it, let alone people 
> coming from other platforms.
> 
> The simplest solution is just to use an atomic operation. Even if there isn’t 
> a standard atomic API in C (as there is in C++), anyone reading the code is 
> probably going to understand what OSAtomicIncrement32() does just from its 
> name.

Surely “anyone reading the code” is going to recognize “dispatch_semaphore” as 
something to do with a semaphore, including people from other platforms? Of 
course, there may still be a lot of programmers from all platforms who don’t 
know what a semaphore is, period.

Anyway, part of my reason for suggesting dispatch_semaphore is that it’s an 
easy, useful tool to know, to make any kind of operation atomic, not just 
incrementing — as well as its more general purpose of managing a pool of 
resources.

It’s also worth noting that *no* direct mechanism for atomic incrementing 
(currently) exists in Swift. There is no language syntax that specifies an 
atomic property, and existing APIs such as OSAtomicIncrement32 do *not* work 
when called from Swift code, because they do not conform to the Swift memory 
model. Presumably this will be remedied at some future time, but until then 
it’s necessary to use alternative strategies such as semaphores.

___

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

Re: How to count Atoms

[Jens Alfke]

> On Oct 7, 2016, at 1:14 AM, Quincey Morris 
>  wrote:
> 
> One straightforward way is to use dispatch_semaphore. IIRC it’s lightweight 
> unless it blocks (that is, unless its count is zero when you wait), so it’s 
> good for this situation where actual contention is rare (assuming actual 
> contention is rare).

IMO dispatch_semaphore is overkill for this; it’s not just an atomic counter, 
it’s also got blocking behaviors for use in e.g. managing a pool of resources. 
I’ll bet that most Mac/iOS programmers don’t know about it, let alone people 
coming from other platforms.

The simplest solution is just to use an atomic operation. Even if there isn’t a 
standard atomic API in C (as there is in C++), anyone reading the code is 
probably going to understand what OSAtomicIncrement32() does just from its name.

—Jens
___

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

Re: How to count Atoms

[Alastair Houghton]

On 7 Oct 2016, at 08:19, Gerriet M. Denkmann  wrote:

> So what is the proper way to count something atomicly and undeprecatedly?

 or  is the approved source for this kind of thing.

In C++, you might write

  #include 

  std::atomic counter;

then you can just do

  ++counter;
  --counter;

as usual, while in C you’d have to write

  #include 

  atomic_int counter;

  atomic_fetch_add(, 1);
  atomic_fetch_sub(, 1);

See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf for the C11 spec 
(section 7.17 is the part you’re interested in), or 
http://en.cppreference.com/w/cpp/atomic for C++11 documentation (you could look 
in the spec also, but personally I find the C++ specification hard to read).

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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

Re: How to count Atoms

[Gerriet M. Denkmann]

> On 7 Oct 2016, at 15:14, Quincey Morris  
> wrote:
> 
> On Oct 7, 2016, at 00:19 , Gerriet M. Denkmann  wrote:
>> 
>> So what is the proper way to count something atomicly and undeprecatedly?
> 
> One straightforward way is to use dispatch_semaphore. IIRC it’s lightweight 
> unless it blocks (that is, unless its count is zero when you wait), so it’s 
> good for this situation where actual contention is rare (assuming actual 
> contention is rare).

Is there a better way than this:
dsema = dispatch_semaphore_create( 0 );  

some loop to be counted
{
dispatch_semaphore_signal(dsema); 
….
}

NSUInteger counter = 0;
for(;;)
{
long a = dispatch_semaphore_wait(dsema, DISPATCH_TIME_NOW);
if ( a != 0 ) break;
counter++;
};

Anyway: to count 20 mio things takes an overhead of ca. 0.5 sec for all of:
OSAtomicIncrement32 — deprecated in macOS 12
atomic_fetch_add_explicit
dispatch_semaphore_signal

IncrementAtomic— deprecated in macOS 8 has overhead of 2.7 sec

> If performance is not a consideration, you can use @synchronized instead. 
> It’s marginally easier to use.

Here the overhead is 2 minutes = 240 times the other counting methods.
Performance is not a consideration, but this is just too much.

Thanks for your help!

Kind regards,

Gerriet.


___

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

Re: How to count Atoms

[Gerriet M. Denkmann]

> On 7 Oct 2016, at 15:43, Ken Thomases  wrote:
> 
> On Oct 7, 2016, at 2:19 AM, Gerriet M. Denkmann  wrote:
>> 
>> I need (just for debugging purposes) to count something in a thread safe 
>> way. 
>> […]
>> So I tried OSIncrementAtomic.
>> Now I get: "Implicit declaration of function 'OSIncrementAtomic' is invalid 
>> in C99" and the linker fails, because it does not find it.
>> #import  does not help at all.
> 
> These problems are all because you're using the wrong name.
> 
> If you #import  then you get the declaration of 
> OSAtomicIncrement32() (among other things).  Note this is not the name you 
> tried (OSIncrementAtomic).  If you use the right name, the compiler warning 
> and linker error will go away.

You are completely right. Following your advice everything works perfectly.

I just typed “OSIncrementAtomic” into Xcode Help and was informed that the 
proper way to use it is:
SInt32 OSIncrementAtomic(volatile SInt32 *address);

The I tried OSAtomicIncrement32 and was told: “No Results”.

This is slightly irritating (and explains why I was using the wrong name).

Thanks a lot for your help!

Kind regards,

Gerriet.


___

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

Re: How to count Atoms

[Ken Thomases]

On Oct 7, 2016, at 2:19 AM, Gerriet M. Denkmann  wrote:
> 
> I need (just for debugging purposes) to count something in a thread safe way. 
> […]
> So I tried OSIncrementAtomic.
> Now I get: "Implicit declaration of function 'OSIncrementAtomic' is invalid 
> in C99" and the linker fails, because it does not find it.
> #import   does not help at all.

These problems are all because you're using the wrong name.

If you #import  then you get the declaration of 
OSAtomicIncrement32() (among other things).  Note this is not the name you 
tried (OSIncrementAtomic).  If you use the right name, the compiler warning and 
linker error will go away.

Regards,
Ken


___

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

Re: How to count Atoms

[Quincey Morris]

On Oct 7, 2016, at 00:19 , Gerriet M. Denkmann  wrote:
> 
> So what is the proper way to count something atomicly and undeprecatedly?

One straightforward way is to use dispatch_semaphore. IIRC it’s lightweight 
unless it blocks (that is, unless its count is zero when you wait), so it’s 
good for this situation where actual contention is rare (assuming actual 
contention is rare).

If performance is not a consideration, you can use @synchronized instead. It’s 
marginally easier to use.

___

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