Ios – queue attributes in dispatch_queue_create

concurrencyios

In Apple's sample code, AVCam-iOS: Using AVFoundation to Capture Images and Movies, I notice this following line:

// Communicate with the session and other session objects on this queue.
self.sessionQueue = dispatch_queue_create( "session queue", DISPATCH_QUEUE_SERIAL );

And I want to know what the second parameter is about and what other options do we have other than DISPATCH_QUEUE_SERIAL?

And what makes it confusing is that in other Apple documentation, it says that the second parameter is reserved and should be set to NULL. It seems either the documentation is out of date, can anyone explain what the second parameter is supposed to be?

The dispatch_queue_create function takes two parameters: the queue name and a set of queue attributes. The queue attributes are reserved for future use and should be NULL. Concurrency Programming Guide

Best Answer

dispatch_queue_t dispatch_queue_create(const char *label, dispatch_queue_attr_t attr);

Queues are created with the dispatch_queue_create() function. Queues, like all dispatch objects, are reference counted and newly created queues have a reference count of one.

The optional label argument is used to describe the purpose of the queue and is useful during debugging and performance analysis. If a label is provided, it is copied. By convention, clients should pass a reverse DNS style label. For example:
my_queue = dispatch_queue_create("com.example.subsystem.taskXYZ", NULL);
The attr argument specifies the type of queue to create and must be either DISPATCH_QUEUE_SERIAL or DISPATCH_QUEUE_CONCURRENT.

From https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/dispatch_queue_create.3.html

Related Solutions

A race condition

A race condition occurs when two or more threads can access shared data and they try to change it at the same time. Because the thread scheduling algorithm can swap between threads at any time, you don't know the order in which the threads will attempt to access the shared data. Therefore, the result of the change in data is dependent on the thread scheduling algorithm, i.e. both threads are "racing" to access/change the data.

Problems often occur when one thread does a "check-then-act" (e.g. "check" if the value is X, then "act" to do something that depends on the value being X) and another thread does something to the value in between the "check" and the "act". E.g:

if (x == 5) // The "Check"
{
   y = x * 2; // The "Act"

   // If another thread changed x in between "if (x == 5)" and "y = x * 2" above,
   // y will not be equal to 10.
}

The point being, y could be 10, or it could be anything, depending on whether another thread changed x in between the check and act. You have no real way of knowing.

In order to prevent race conditions from occurring, you would typically put a lock around the shared data to ensure only one thread can access the data at a time. This would mean something like this:

// Obtain lock for x
if (x == 5)
{
   y = x * 2; // Now, nothing can change x until the lock is released. 
              // Therefore y = 10
}
// release lock for x

A mutex

When I am having a big heated discussion at work, I use a rubber chicken which I keep in my desk for just such occasions. The person holding the chicken is the only person who is allowed to talk. If you don't hold the chicken you cannot speak. You can only indicate that you want the chicken and wait until you get it before you speak. Once you have finished speaking, you can hand the chicken back to the moderator who will hand it to the next person to speak. This ensures that people do not speak over each other, and also have their own space to talk.

Replace Chicken with Mutex and person with thread and you basically have the concept of a mutex.

Of course, there is no such thing as a rubber mutex. Only rubber chicken. My cats once had a rubber mouse, but they ate it.

Of course, before you use the rubber chicken, you need to ask yourself whether you actually need 5 people in one room and would it not just be easier with one person in the room on their own doing all the work. Actually, this is just extending the analogy, but you get the idea.

Best Answer

Related Solutions

A race condition

A mutex

Related Topic