41

I maintain a dispatch queue as a property with my view controller. I create this queue once in my view controller's init method, and reuse a few times for some background tasks. Before ARC, I was doing this:

@property (nonatomic, assign) dispatch_queue_t filterMainQueue;

And in init:

if (filterMainQueue == nil) {
     filterMainQueue = dispatch_queue_create("com.myQueue.CJFilterMainQueue", NULL);
}

But after ARC, I'm not sure if this should still be "assign", or should it be "strong" or "weak". The ARC convertor script didn't change anything but I'm not sure if a subtle bug is coming from the fact that this queue might be deallocated while it's being used?

What would be the difference between the 3 types of properties, and what will work the best for a dispatch queue, when using ARC?

Z S
  • 7,039
  • 12
  • 53
  • 105

5 Answers5

63

Updated answer:

In current OS X and iOS, Dispatch objects are now treated as Obj-C objects by ARC. They will be memory-managed the same way that Obj-C objects will, and you should use strong for your property.

This is controlled by the OS_OBJECT_USE_OBJC macro, defined in <os/object.h>. It's set to 1 by default when your deployment target is OS X 10.8 or higher, or iOS 6.0 or higher. If you're deploying to an older OS, then this is left at 0 and you should see my original answer below.

Original answer:

Dispatch objects (including queues) are not Obj-C objects, so the only possible choice is assign. The compiler will throw an error if you try to use strong or weak. ARC has no impact on GCD.

Lily Ballard
  • 182,031
  • 33
  • 381
  • 347
  • @JimThio: [Grand Central Dispatch](http://developer.apple.com/library/ios/#documentation/Performance/Reference/GCD_libdispatch_Ref/Reference/reference.html) – Lily Ballard May 18 '12 at 06:16
  • 13
    This is no longer true in Mountain Lion - see /usr/include/os/object.h. GCD and XPC "objects" (anything you might explicitly release) now behave enough like ObjC objects that they can participate in ARC. – jkh Aug 28 '12 at 00:13
  • @jkh does that include the iOS platform as well? – Ankur Jan 06 '13 at 05:29
  • 1
    @Ankur: As of iOS 6.0, yes. – Lily Ballard Jan 06 '13 at 19:40
  • @KevinBallard Given that this is the accepted answer but is now wrong (as the comments note), you should edit your answer so people don't get wrong information. – kevlar Feb 12 '14 at 08:40
  • 2
    It is a good idea to check not if support present, but rather if it's in use. check for `OS_OBJECT_USE_OBJC` instead – ReDetection Oct 25 '15 at 05:18
  • So you use `strong` but no asterisk. Ok! – Dan Rosenstark Apr 28 '16 at 21:39
9

Here is how one would define dispatch_queue_t property for iOS 6.0 and above AND below iOS 6.0

#if OS_OBJECT_HAVE_OBJC_SUPPORT == 1
@property (nonatomic, strong) dispatch_queue_t serialDispatchQueue;
#else
@property (nonatomic, assign) dispatch_queue_t serialDispatchQueue;
#endif

Basically OS_OBJECT_HAVE_OBJC_SUPPORT is defined as 1 for iOS 6.0 and above. (MAC 10.8 and above). Below iOS 6 it is defined as 0.

OS_OBJECT_HAVE_OBJC_SUPPORT defines that OS objects like GCD have objective C support. So ARC, memory management, reference counting etc. applies to GCD objects.

Kris Subramanian
  • 1,850
  • 18
  • 15
5

Here is what I use:

@property (readwrite, strong, nonatomic) __attribute__((NSObject)) dispatch_queue_t queue;
Arvin
  • 2,516
  • 27
  • 30
  • 2
    It basically turns a non-ObjC object into an ObjC property so you can easily use it like self.queue – Arvin Jan 24 '13 at 03:51
  • @Arvin Something changed with 6.1 that affected this. It complained about __attribute__ and removing it seems to work now. I haven't run into any issues so I'm guessing property (readwrite, strong, nonatomic) dispatch_queue_t queue is safe? – jer-k Jan 30 '13 at 02:49
  • 1
    I would agree...those crazy folks at Apple. What will they do next? ;-) – Arvin Jan 30 '13 at 04:29
4

Based on iOS7, I tested whether dispatch_queue object is an objective-C object and I figured out they already are objective-c object. to paraphrase this, attribute((NSObject)) is not necessary now.

Sungwook Kim
  • 356
  • 1
  • 3
  • 11
1

TL;DR: dispatch_queue_t is an Objective C object now and can be managed with ARC.

I haven't tested how far back this is true, but using the iOS 7 SDK and Xcode 5, dispatch_queue_t is an object type. I am declaring a property for a queue as 

@property (nonatomic, strong) dispatch_queue_t syncQueue;

The compiler is happy and everything works as expected. I know definitively that this used to not work in iOS 4 or 5 (pre-ARC it was retain instead of strong). I dug into the definition for dispatch_queue_t and found this:

/*!
 * @typedef dispatch_queue_t
 *
 * @abstract
 * Dispatch queues invoke blocks submitted to them serially in FIFO order. A
 * queue will only invoke one block at a time, but independent queues may each
 * invoke their blocks concurrently with respect to each other.
 *
 * @discussion
 * Dispatch queues are lightweight objects to which blocks may be submitted.
 * The system manages a pool of threads which process dispatch queues and
 * invoke blocks submitted to them.
 *
 * Conceptually a dispatch queue may have its own thread of execution, and
 * interaction between queues is highly asynchronous.
 *
 * Dispatch queues are reference counted via calls to dispatch_retain() and
 * dispatch_release(). Pending blocks submitted to a queue also hold a
 * reference to the queue until they have finished. Once all references to a
 * queue have been released, the queue will be deallocated by the system.
 */
DISPATCH_DECL(dispatch_queue);

By the sounds of that, it shouldn't work, so I checked the definition of DISPATCH_DECL and found this, which explains everything:

/*
 * By default, dispatch objects are declared as Objective-C types when building
 * with an Objective-C compiler. This allows them to participate in ARC, in RR
 * management by the Blocks runtime and in leaks checking by the static
 * analyzer, and enables them to be added to Cocoa collections.
 * See <os/object.h> for details.
 */
Holly
  • 5,270
  • 1
  • 24
  • 27