Nastal čas na kakao - Málem bychom zapomněli: NSAutoreleasePool - MujMAC.cz - Apple, Mac OS X, Apple iPod

30. března 2005, 00.00 | Pokud bychom chtěli dodržet pořadí, v němž jsme se o třídách Foundation Kitu zmínili v úvodním přehledovém článku (a to bychom měli, aby bylo snadné se v nich orientovat), neměli jsme začínat kontejnerovými třídami NS(Mutable)Array, ale třídou NSAutoreleasePool, v níž (spolu s některými službami třídy NSObject) je skryto celé kouzlo poloautomatického garbage collectoru firmy NeXT – pardon, firmy Apple ☺.

Pokud bychom chtěli dodržet pořadí, v němž jsme se o třídách Foundation Kitu zmínili v úvodním přehledovém článku (a to bychom měli, aby bylo snadné se v nich orientovat), neměli jsme začínat kontejnerovými třídami NS(Mutable)Array, ale třídou NSAutoreleasePool, v níž (spolu s některými službami třídy NSObject) je skryto celé kouzlo poloautomatického garbage collectoru firmy NeXT – pardon, firmy Apple ☺.

Ovšem, pro pochopení příkladů kódu, jež zde uvádíme, je vhodné, abychom už měli za sebou alespoň povídání o třídě NSValue, a v navazujícím příštím článku o výjimkách bude dobře rozumět distribuovaným objektům. Proto zmíněné "přehlédnutí" napravíme až dnes: vysvětlíme si, jaké je postavení třídy NSAutoreleasePool ve Foundation Kitu, a ukážeme si, jakým způsobem podporuje automatický zánik objektů "když je to zapotřebí".

Základy

Základy správy paměti v Cocoa jsme si už vysvětlili dávno, hned na začátku našeho seriálu v článku, věnovanému vzniku a zániku objektů. Nyní proto zopakujeme jen ta nejzákladnější pravidla (jež si dnes upřesníme a podrobněji vysvětlíme):

• objekt, který explicitně vytvoříme kombinací zpráv alloc/init..., pomocí zastaralé zprávy new, nebo pomocí zpráv copy a mutableCopy, není spravován garbage collectorem: musíme jej proto explicitně uvolnit pomocí zprávy autorelease nebo release;
• získáme-li objekt jakkoli jinak, je spravován garbage collectorem, a zanikne (nějaký čas) po ukončení metody, v níž jsme jej získali. Budeme-li jej potřebovat déle, musíme si jej explicitně "přidržet" pomocí zprávy retain;
• objekt, jemuž jsme poslali zprávu retain, musíme – až pokud jej přestaneme potřebovat – uvolnit pomocí zprávy autorelease nebo release, stejně, jako objekt, jenž jsme sami vytvořili (v prvém bodě).

Připomeňme ještě v rychlosti rozdíl mezi zprávami autorelease a release: zatímco první zajistí, že objekt zanikne někdy po ukončení metody, v níž jsme jej použili, po přijetí zprávy release může objekt zaniknout ihned. Použití zprávy release je tedy obecně o něco efektivnější, ale také potenciálně nebezpečné.

Základem celého systému správy paměti v Cocoa – zapomeneme-li na chvilku na zprávu autorelease – je prachobyčejné počítání referencí: kdykoli objekt dostane zprávu retain, inkrementuje vnitřní čítač; kdykoli dostane zprávu release, opět jej dekrementuje – a pokud došel k nule, zanikne.

Skutečné kouzlo a programátorské pohodlí ale zajišťuje právě možnost používat zprávu autorelease: bez ní bychom kupříkladu nemohli rozumně (tedy bez starostí o to, kdo vlastně má objekt uvolnit) předávat objekty mezi různými metodami a podobně. Nu, a právě služby zprávy autorelease jsou ve skutečnosti zajišťovány právě třídou NSAutoreleasePool.

Základní princip je hrozně jednoduchý: instance třídy NSAutoreleasePool v podstatě není ničím jiným, nežli kontejnerem, schopným obsahovat objekty. Pošleme-li nějakému objektu zprávu autorelease, nestane se nic jiného, než že se tento objekt uloží do právě aktivního kontejneru NSAutoreleasePool; po nějakém čase standardní aplikační knihovny tento kontejner zruší – a on sám prostě při svém zániku pošle zprávu release všem objektům, jež v něm byly uloženy. Standardní aplikační knihovny pak vytvoří automaticky nový NSAutoreleasePool, a to je vlastně všechno...

Princip funkce

Ukažme si pro lepší ilustraci zdrojový kód takového velmi primitivního kontejneru, který bude – až na efektivitu a některé pomocné služby, jež si popíšeme za chvíli – fungovat prakticky stejně, jako standardní NSAutoreleasePool. Pro ukládání objektů využijeme standardní NSMutableArray a NSValue pro jejich ukládání bez "retainu"; zároveň implementujeme pomocné služby pro udržování "aktuálního poolu":

@interface DumbAutoreleasePool:NSObject {
  NSMutableArray *contents;
  DumbAutoreleasePool *previousPool;
}
+(void)addObject:object; // přidá objekt do aktivního poolu
-(void)addObject:object; // přidá objekt do příjemce
@end
@implementation DumbAutoreleasePool
static DumbAutoreleasePool *currentPool=nil;
-init {
  if (!(self=[super init])) return nil;
  contents=[[NSMutableArray alloc] init];
  // pokud byl aktuální jiný pool, zapamatujeme si jej
  // a sebe sama do něj uložíme (za chvíli uvidíme proč)
  [previousPool=currentPool addObject:self];
  // a nastavíme sebe sama jako aktuální
  currentPool=self;
  return self;
}
+(void)addObject:object {
  [currentPool addObject:object];
}
-(void)addObject:object {
  [contents addObject:[NSValue valueWithNonretainedObject:object]];
}
-(void)removeObject:object { // interní služba, viz níže
  [contents removeObject:[NSValue valueWithNonretainedObject:object]];
}
-(void)dealloc {
  // nejprve uvolníme všechny objekty z poolu
  NSEnumerator *en=[contents objectEnumerator];
  id o;
  while (o=[en nextObject])
    [[o nonretainedObjectValue] release];
  // zrušíme kontejner, obnovíme current pool, a to je vše
  [contents release];
  [currentPool=previousPool removeObject:self];
  [super dealloc];
}
@end

Samozřejmě, ještě bychom museli implementovat ekvivalent služby autorelease nějak takto:

@implementation NSObject (DumbAutoreleasePoolCategory)
-dumbAutorelease {
  [DumbAutoreleasePool addObject:self];
  return self;
}
@end

Ačkoli standardní NSAutoreleasePool je naprogramován lépe a efektivněji a nabízí některé další služby, v principu dělá přesně tohle, včetně toho hierarchického řetězení prostřednictvím proměnné previousPool, jež umožňuje pooly vzájemně vnořovat – k tomu se za chvilinku vrátíme.

Vytváření a rušení poolů

Ovšem, aby náš kód byl vůbec k něčemu dobrý, a aby služba dumbAutorelease dělala něco rozumného, musí nějaký kód nejprve vytvořit náš pool, a pak jej opět zrušit a vytvořit nový – v praxi by to, v hodně jednoduchém případě, mohlo vypadat asi nějak takhle:

int main() {
  int cc; // dejme tomu, že budeme číst standardní vstup
  while ((cc=getchar())!=EOF) {
    DumbAutoreleasePool *pool=[[DumbAutoreleasePool alloc] init];
	...
	... tento kód může používat dumbAutorelease ...
	...
	[pool release];
  }
  return 0;
}

V zásadě přesně tohle – ale v mnohem komplexnější podobě, kde se namísto prostého čtení standardního vstupu zpracovávají všechny možné vstupní události, od klávesnice a myši přes časovač až po zprávy, předávané mezi aplikacemi prostřednictvím distribuovaných objektů – dělá standardní kód z knihoven Cocoa s NSAutoreleasePoolem. Právě díky tomu máme kdykoli k dispozici aktuální pool, do nějž můžeme objekty ukládat pomocí zprávy autorelease, a právě díky tomu tyto objekty (pokud je, samozřejmě, někdo neretainoval) zaniknou automaticky ve chvíli, kdy končí zpracování právě aktuální události.

Hierarchie poolů

K čemu je výše zmíněné hierarchické vnořování poolů vlastně dobré? Inu, pozorní čtenáři už si to asi sami uvědomili: pokud je to zapotřebí, můžeme pooly stejně dobře vytvářet sami; zapotřebí to bude tehdy, když v rámci zpracování jediné události vytváříme příliš mnoho objektů, takže aktuální NSAutoreleasePool by příliš narostl a jeho zpracování by trvalo příliš dlouho:

...
// nešikovný kód
for (int i=0;i<1000000;i++) {
  NSString *s=[NSString stringWithFormat:@"číslo %d",i];
  if (i%1) s=[s stringByAppendingString:@" je liché"];
  NSArray *slova=[s componentsSeparatedByString:@" "];
  ...
}
...

V takovýchto případech se vyplatí použít vlastní vnořený pool, který uvolníme buďto na konci každého cyklu

...
// lepší varianta
for (int i=0;i<1000000;i++) {
  NSAutoreleasePool *pool=[[NSAutoreleasePool alloc] init];
  NSString *s=[NSString stringWithFormat:@"číslo %d",i];
  if (i%1) s=[s stringByAppendingString:@" je liché"];
  NSArray *slova=[s componentsSeparatedByString:@" "];
  ...
  [pool release]; // zde se uvolní vše, co se v těle cyklu
    // vytvořilo (a co jsme si nepřidrželi zprávou 'retain')
}
...

nebo – pokud cyklus běží mnohokrát a jeho obsah je poměrně jednoduchý – až po několika průchodech:

...
// ještě lepší
NSAutoreleasePool *pool=[[NSAutoreleasePool alloc] init];
for (int i=0;i<1000000;i++) {
  ...
  if (i%100==99) {
    [pool release];
	pool=[[NSAutoreleasePool alloc] init];
  }
}
[pool release];
...

Až si příště budeme povídat o výjimkách a jejich zpracování, pochopíme také, proč jsme vkládali vnořený pool do poolu nadřízeného: jde o to, že náš kód může "vyskočit ven" – třeba takhle, nahradíme-li dosud nepopsaný mechanismus výjimek starým dobrým goto:

...
for (int i=0;i<1000000;i++) {
  NSAutoreleasePool *pool=[[NSAutoreleasePool alloc] init];
  ...
  if (...) goto Out;
  ...
  [pool release];
}
Out:
...

Na první pohled to vypadá velmi podezřele a nezdravě: vždyť jsme vytvořili nový pool a při výskoku jsme jej neuvolnili – nezůstanou jeho objekty "viset" v paměti "navěky" (tedy do ukončení procesu)? Inu, nezůstanou, právě díky "fintě" s uložením vnořeného poolu do poolu nadřízeného – ve chvíli, kdy jsme pool vytvořili, jsme jej uložili do poolu, jenž byl tehdy aktuální; až se tedy ten bude uvolňovat (nejspíš na konci zpracování události), zanikne i náš vnořený pool.