Atomics in Objective-C

Also, why talk about performance and then make obj-c method calls...?

It's quite easy using NSProxy to create a throttler that will wrap any object, then you can abstract throttling from the behavior of the underlying object.

  @interface Throttler : NSProxy {
     dispatch_semaphore_t _semaphore;
     id _object;
  }
  - initWithObject:(id)obj concurrentOperations:(int)ops;

  @end
  @implementation Throttler

  - (id) initWithObject:(id)obj concurrentOperations:(int)ops {
     if(self = [super init]){
       _semaphore = dispatch_semaphore_create(ops)
       _object = obj;
     }
     return self;
  }

  - (void) forwardInvocation:(NSInvocation*)invocation {
     if(dispatch_semaphore_wait(_semaphore,0)){
        @try {
        [invocation setTarget: _object];
        [invocation invoke];

        }
        @catch (NSException* e){
          @throw e;
        }
        @finally {
        dispatch_semaphore_signal(_semaphore);
        }
        return;
     }
     @throw [NSException
          exceptionWithName:@"InsufficientResourceException"
          reason:@"Insufficient Resource"
          userInfo:nil];
  }

  @end 

The most Cocoa-compatible way of handling background execution of expensive procedures is always going to be best executed, quickest, using Grand Central Dispatch.

For example:

    @interface Foo ()
    @property (nonatomic) dispatch_queue_t backgroundQueue;
    @end
    
    @implementation Foo

    - (BOOL) veryExpensiveMethod:(id)arg completion:(void (^)())completion {
        dispatch_async(self.backgroundQueue, ^{
            if (_counter++ > N) {
                _counter--;
                return NO;
            }
            // Critical section
            _counter--;
            return YES;
            dispatch_async(dispatch_get_main_queue(), completion);
        };

These problems have been solved, better.

This is a pet peeve of mine, to call that an "OS" feature. In all recent CPUs I know of, atomic ops are not a privileged operation, and there is absolutely nothing for the operating system to manage in a traditional sense. You don't trap into the kernel and have it compare-and-swap, you just, um, compare and swap.

Maybe your OS provides a convenient C API, but it is not "OS" functionality. It's just instructions on your CPU. You could just as well write them inline. In many common uses, that's what ends up happening - the atomic ops are put inline with the rest of your code.

(I suspect it probably is, but fundamentally, @synchronize is implemented using compare and swap / other processor atomics, so it's probable that the difference is very slight - e.g. there's only a measurable difference if the thread is descheduled while holding a lock).