GCD y subprocesss

Quiero entender algo sobre GCD y Threads.

Tengo un bucle for en mi controller de vista que le pide a mi model que realice una request de networking asíncrona.

Entonces, si el ciclo se ejecuta 5 veces, el model envía 5 requestes de networking.

¿Es correcto decir que mi model creó 5 subprocesss teniendo en count el hecho de que estoy usando la respuesta sendAsyncRequest de NSURLConnection y los controlleres de finalización se invocarán con 5 subprocesss adicionales?

Ahora, si le pido a mi controller de vista que ejecute esto para bucle en un hilo diferente y en cada iteración del bucle, la llamada al model debería depender de la iteración anterior, ¿estaré creando un "Inicio" de hilos aquí?

Básicamente, quiero las requestes asíncronas posteriores a mi server solo si el hilo anterior se ha completado por completo (Por completo me refiero a que todos sus subprocesss también deberían haber terminado de ejecutarse).

Ni siquiera puedo enmarcar la pregunta correctamente porque estoy masivamente confundido. Pero si alguien puede ayudar con algo, eso sería útil.

No es correcto indicar que se han creado cinco subprocesss en el caso general.

No hay un mapeo uno a uno entre subprocesss y bloques. GCD es una implementación de agrupación de subprocesss.

Se crea una cierta cantidad de subprocesss según la configuration óptima para ese dispositivo: el costo de crear y mantener subprocesss en esa versión del sistema operativo, la cantidad de núcleos de procesador disponibles, la cantidad de subprocesss que ya posee, pero que actualmente están bloqueados y cualquier otro factor en el que Apple se preocupe por tener en count puede ser relevante.

GCD luego distribuirá tus bloques sobre esos hilos. O puede crear nuevos hilos. Pero no necesariamente.

Más allá de eso, las queues son solo forms de establecer la secuencia entre bloques. Una queue de envío en serie no necesariamente posee su propio hilo. Todas las queues de envío simultáneas no necesariamente poseen sus propios hilos. Pero no hay razón para creer que cualquier set de queues comparta hilos.

Los medios exactos para seleccionar hilos para bloques han cambiado entre las versiones del sistema operativo. Por ejemplo, iOS 4 fue un gran libertador en la creación de subprocesss, de una manera que iOS 5+ definitivamente no había sido.

GCD intentará hacer lo que sea mejor en las circunstancias. No pierdas el time tratando de adivinarlo por segunda vez.

"Básicamente, quiero las requestes asíncronas posteriores a mi server solo si el hilo anterior se ha completado por completo (Por completo me refiero a que todos sus sub hilos también deberían haber terminado de ejecutarse)."

Solo centrándose en la statement anterior para evitar confusiones. Una solución simple sería crear una queue. Alimente la queue con 5 loops. Cada ciclo realizará una request de networking de manera síncrona (puede usar sendSynchronousRequest: método disponible en NSURLConnection), realizar las operaciones después de completar la request y luego comenzar el siguiente ciclo. la queue siguiendo FIFO ejecutará sus requestes posteriormente.

GCD: piense en esto como una simple queue que puede aceptar tareas. Las tareas son bloques de su código. Puede poner tantas tareas como desee en una queue (permitiendo los límites del sistema). Las queues vienen en diferentes sabores. Concurrente vs Serial. Principal vs Global. Alta Prioridad vs Baja Prioridad. Una queue no es un hilo.

Hilo: es una sola línea de ejecución de código en secuencia. Puede tener varios subprocesss trabajando en su código al mismo time. Un hilo no es una queue.

Una vez que separe las 2 entidades, las cosas comienzan a quedar claras.

GCD básicamente usa los hilos en el process para trabajar en tareas. En una queue de serie, todo se procesa en secuencia. Por lo tanto, no necesita tener mecanismos de synchronization en su código, la misma naturaleza de la queue de serie garantiza la synchronization. Si se trata de una queue simultánea (es decir, se procesan 2 o más tareas al mismo time, debe asegurarse de que las secciones críticas de su código estén protegidas con synchronization).

Aquí es cómo hacer queue para hacer.

dispatch_async(_yourDispatchQueue, ^() { NSLog (@"work queued"); }); 

El NSLog anterior ahora se ejecutará en un hilo de background en un futuro cercano, pero en un hilo de background.

Si nota que cuando solicitamos, utilizamos dispatch_async. La otra variante es dispatch_sync. Lo diferente entre los 2 es después de poner la request en la queue, la variación asincrónica se moverá. ¡La variación de synchronization no lo hará!

Si va a usar un GCD para NSURLConnection, debe tener cuidado en qué subprocess iniciar la connection. Aquí hay un enlace SO para más información. GCD con NSURLConnection