5

In iOS app development, we are using NSAutoreleasePool to relinquish ownership of objects at a later point in time.

But why can it be shared between different threads?

Why do we need to create a new autoreleasepool when I wanted to use a new thread?

EDIT:

As taskinoor mentioned my question was why this is designed in such a way that each thread should have a separate autoreleasepool.

Daniel
  • 23,129
  • 12
  • 109
  • 154
RK-
  • 12,099
  • 23
  • 89
  • 155
  • 1
    [This question seems very related to your question](http://stackoverflow.com/questions/4547652/does-every-thread-need-its-own-autorelease-pool) – Michael Dautermann Aug 04 '12 at 13:05
  • 1
    You should think about using `@autoreleasepool { ... }` instead of `NSAutoreleasePool`. According to the documentation, it is more efficient. And if you migrate to ARC, it is mandatory. – Martin R Aug 04 '12 at 13:07
  • I don't know why you needed that edit, my answer explains the reason for it :) –  Aug 04 '12 at 13:18

4 Answers4

5

The design challenge for multi-thread autorelease pools is when to drain them. If you drain the pool while an object is still being used, then you will crash. Per thread, it's easy to tell when you are outside the run loop and thus at a point where autoreleased objects can be drained. In a multi-thread situation, your threads would need to be synchronized at the end of their runloop so you can be sure you are at a safe point to drain them. Synchronized treads in this way is a bad idea, it creates lots of idle time and slows down the program.

Jeffery Thomas
  • 42,202
  • 8
  • 92
  • 117
  • 1
    Take it one step further; if any thread is blocked waiting for anything -- network, thread state, other I/O -- then the overall pool could not be drained. – bbum Aug 04 '12 at 16:09
2

Each thread is a different execution context - one thread may exit sooner or later, they might use different resources with different lifetimes and memory managementt needs, so each thread should be managed independently.

1

Because they designed in this way. I guess your question is why they designed in this way. I am not 100% sure, but one possible reason may be that sharing a resource across threads has its cost. During every modification to the shared pool each thread will need to lock-unlock that which will reduce the performance. A resource should be shared across multiple threads only if that sharing is necessary which is not the case with autorelease pools. Using dedicated autorelease pool will perform better. This could be one possible reason for this design decision.

taskinoor
  • 45,586
  • 12
  • 116
  • 142
  • 1
    Good guess, but incomplete. Autorelease pools must be per-thread because there would be no way to safely drain the pool without *all threads* being in a state where their pool could be drained. If *any thread* is blocked waiting for input, then the drain could not happen. Jeffeery's answer is correct. – bbum Aug 04 '12 at 16:08
  • 1
    @bbum, thanks. I didn't think about draining the pool and I agree that Jeffery's answer is better than mine. – taskinoor Aug 04 '12 at 16:21
0

I don't think the autorelease pools are shared between threads, according to apples memory management guide in Cocoa each thread has its own stack of autorelease pools

If you don't create an autorelease pool for threads which you create or detach, then the autorelease function doesnt work, so the memory footprint will grow

wattson12
  • 11,176
  • 2
  • 32
  • 34