¿Por qué necesitamos usar NSAutoreleasepool para cada hilo?

Question

En el desarrollo de aplicaciones iOS, estamos usando NSAutoreleasePool para renunciar a la propiedad de los objetos en un momento posterior.

¿Pero por qué se puede compartir entre diferentes subprocesos?

¿Por qué tenemos que crear un nuevo autoreleasepool cuando quería usar un nuevo hilo?

EDIT:

Como taskinoor mencionado mi pregunta era por qué esto está diseñado de tal manera que cada hilo debe tener un autoreleasepool separada.

Answer 1

El desafío de diseño para las agrupaciones de autorrelease de múltiples hilos es cuándo drenarlos. Si drena la piscina mientras un objeto todavía se está utilizando, se bloqueará. Según el hilo, es fácil saber cuándo se encuentra fuera del ciclo de ejecución y, por lo tanto, en un punto en el que los objetos liberados automáticamente se pueden drenar. En una situación de múltiples hilos, sus hilos necesitarían estar sincronizados al final de su recorrido para que pueda estar seguro de que está en un punto seguro para drenarlos. Las huellas sincronizadas de esta manera son una mala idea, crean mucho tiempo de inactividad y ralentizan el programa.

Answer 2

No creo que las piscinas autorelease son compartidos entre los hilos, de acuerdo con apples memory management guide en Cocoa cada hilo tiene su propia pila de piscinas autorelease

Si no se crea una piscina autorelease de hilos que se crean o separar, entonces la función de liberación automática no funciona, por lo que la huella de memoria crecerá

Answer 3

Cada subproceso tiene un contexto de ejecución diferente: un subproceso puede salir tarde o temprano, pueden usar diferentes recursos con diferentes vidas y necesidades de administración de memoria, por lo que cada hilo debe ser administrado de forma independiente.

Answer 4

Porque diseñaron de esta manera. Supongo que tu pregunta es por qué diseñaron de esta manera. No estoy 100% seguro, pero una posible razón puede ser que el hecho de compartir un recurso entre subprocesos tiene su costo. Durante cada modificación en el conjunto compartido, cada subproceso tendrá que bloquear y desbloquear lo que reducirá el rendimiento. Un recurso se debe compartir en varios subprocesos solo si es necesario compartirlo, que no es el caso con los grupos de liberación automática. El uso del pool de autorrelease dedicado tendrá un mejor rendimiento. Esta podría ser una de las posibles razones para esta decisión de diseño.