Skippov blog

Singletony, HttpContext a ThreadStatic alebo čo je v skutočnosti private-local v ASP.NET

Ahoj všetci. Nakoľko je toto môj prvý post na tomto blogu, rád by som na úvod napísal pár vecí o mne a o tom, čomu sa chcem venovať. Programujem už nejaký ten rôčik, mal som tú česť pracovať na širokej škále projektov, od windows a web aplikácii, cez skriptovacie jazyky, až po komplikovanejšie paralelné aplikácie na Linuxovom klastri. S ASP.NET robím pomerne krátko, takže moje príspevky profíkom zrejme veľa nedajú, no ďalšie generácie slovenských, a možno aj českých programátorov, tu možno objavia stratégiu bojov, ktoré sme zvádzali snáď všetci. A v neposledom rade možno svojou troškou podporím slovenskú a českú .NET komunitu. Myslím, že som konečne objavil oblasť (.NET, webové aplikácie), ktorej sa chcem dlhodobo venovať. V práci sa venujem prevažne užívateľskej strane projektov, moje príspevky sa budú týkať oblastí ako Ajax, JavaScript, CSS, ASP.NET a bezpečnosť. Opakujem prevažne. :-) V rámci toho mála voľného času sa zaoberám grafikou a tvorbou oldschool hier. Ak má niekto podobné hobby, ozvite sa, rád si pokecám a vymením skúsenosti. A teraz späť k téme.

Singleton je už klasik medzi návrhovými vzormi (design patterns). Jednoducho povedané, termín singleton reprezentuje triedu, ktorá umožní vytvoriť práve a iba jednu jej inštanciu. Zvyčajne k jej metódam a vlastnostiam pristupujeme veľmi jednoducho, a to cez statickú vlastnosť (property), ktorá vráti inštanciu triedy, ak je vytvorená. V opačnom prípade ju vytvorí a vráti inštanciu. Spomínaná vlastnosť garantuje maximálne jednú inštanciu triedy. Načo je nám taký singleton dobrý? V prvom rade umožňuje tzv. lazy instantiation, čo voľne preložené znamená, že inštancia triedy sa vytvorí až v momente, ked budeme k triede pristupovať (ak vôbec). Ďalej oproti static metódam a properties je singleton trieda thread-safe, t.j. volanie metód sa nám nezgulášuje. Tu nie som celkom presný, singleton môže byť implementovaný ako not-thread-safe, takejto implementácii by sme sa mali vyhnúť.

Príklad je lepší ako sto slov, preto ukážka jednoduchého thread-safe singletonu:

public class MojSingleton
{
    private static MojSingleton m_oInstance=null;
    private static readonly object padlock = new object();

    private MojSingleton ()
    {
    }

    public static MojSingleton oInstance
    {
        get
        {
            lock (padlock)
            {
                if (m_oInstance==null)
                {
                    m_oInstance = new MojSingleton();
                }
                return m_oInstance;
            }
        }
    }
}

Pre tých, ktorí budú ohŕňať nos nad zamykaním obsahu gettera, napíšem len to, že je to rovnaký problém ako klasická snaha programátorov o optimalizáciu použitia premenných alebo volania funkcie, ktorá je v dobe dnešných kompilátorov zanedbateľná. Toto v 99% nie je úzke miesto programu (bottleneck) a osobne by som sa pozrel na volanie databáz, ajax callbackov resp. dynamickú úpravu obsahu napríklad javascriptom.

Takáto implementácia je fajn, ale čo v prípade ASP.Net, kde nám každý request obsluhuje jeden z niekoľkých threadov poolu a my nechceme zdieľať pre všetky requesty jeden singleton? Šikovný pán Roman Macháček ponúka modifikované riešenie:

public class Singleton
{
    private Singleton()  {}

    public static Singleton Instance
    {
        get 
        {
            if (HttpContext.Current.Session["Singleton"]==null)
                HttpContext.Current.Session["Singleton"]=new Singleton();
            return (Singleton)HttpContext.Current.Session["Singleton"];
        }
    }
}

Niektoré moje singletony zgrupujú iba metódy a volanie konštruktora je zanedbateľné, preto sa mi ukladanie singletonu do objektu Session velmi nepozdávala. V prípade, že by som v triede ukladal nejaké privátne dáta a potreboval ich držať pre daný request počas celej session, hore uvedená implementácia by mi úplne vyhovovala. Avšak ako každý programátor, v túžbe optimalizovať moju aplikáciu som začal hľadať riešenie, ako vytvárať singleton na úrovni requestu. T.j. po zavolaní Request_End funkcie by sa singleton pekne a čisto odpratal. Pokiaľ možno automaticky. Pri svojom pátraní som sa dostal k parametru [ThreadStatic]. Aplikácia tohto parametra na static field spôsobí, že thready si nebudú field zdieľať, ale každý thread bude mať svojú vlastnú inštanciu threadu. (Poznámka na okraj: ako by ste do slovenčiny preložili termín field?). Vyzerá to dobre, stačí ak modifikujeme prvý príklad singletonu a sme za vodou. Teraz sa priznám, že som to neskúšal a neviem povedať, aké situácie by bolo treba riešiť. Uvádzam preto ešte jeden príklad singletonu, ktorý je thread-safe, ale bez uzamykania. Túto verziu budú preferovať odporcovia príkazu lock :-) A ostatní, ktorí sa s touto implementáciou ešte nestretli, sa niečo nové dozvedia. Pokial volanie konštruktora nie je časovo náročné a nespôsobí nejaké vedľajšie účinky, vo veľa prípadoch si vystačíte nie celkom lazy singletonom:

public class MojSingleton
{
    [ThreadStatic] 
    private static readonly MojSingleton m_oInstance=new MojSingleton();

    // Explicit static constructor to tell C# compiler
    // not to mark type as beforefieldinit
    private static MojSingleton()
    {
    }

    private MojSingleton()
    {
    }

    public static MojSingleton oInstance
    {
        get
        {
            return m_oInstance;
        }
    }
}

[ThreadStatic] je fajn, ale nefunguje tak, ako by ste na prvý pohľad očakávali. Dá sa použiť iba v niektorých situáciach. Vysvetlím. Keď som sa dozvedel o tomto attribúte, už od začiatku ma sprevádzala akási nedôvera. Static fieldom veľmi neverím, preto aj tie pochybnosti ohľadom už toľkokrát spomínaného atribútu. Skúmal som teda ďalej, aké sú reálne možnosti jeho použitia.

“Aj ked si myslíš, že vieš čo robíš, NIE je bezpečné ukladať čokoľvek v ThreadStatic fielde, CallContext-te alebo Thread Local Storage v prípade ASP.NET aplikácie, ak je nejaká šanca, že hodnota bude nastavená pred volaním Page_Load (napríklad v IHttpModule alebo konštruktore stránky) a pristupovať sa k nej bude počas nej alebo neskôr” Piers7.

Piers vo svojom blogu dobre rozanalyzoval otázky okolo spracovania requestu ASP.Net-tom. Problém s ThreadStatic atribútom spočíva v tom, že ASP.NET nie je iba thread-pooled ale aj thread agile (-: Opäť otázka pre náruživého čitateľa: Ako preložiť posledné slovné spojenie do rodnej materčiny? :-) Zjednodušene povedané, ASP.NET každému requestu pridelí nejaký thread z poolu. Tých treadov je tam štandardne cca 25 (?). Tu je kameň úrazu, pretože neplatí tvrdenie: request je obsluhovaný threadom od jeho začiatku do konca. To anglické thread agile znamená, že ASP.NET môže (a robí) prepnúť thready počas spracovávania requestu a dokáže obslúžiť viac requestov jedným threadom. A teda jeden request može byť spracovaný viacerými threadmi. Nemáme kontrolu nad Thread Pool a životným cyklom threadov, preto atribút [ThreadStatic] nefunguje ako privátny a lokálny v rámci requestu, ale ako privátny a lokálny medzi všetkými threadmi poolu. Ak vieme kontrolovať thready, potom aj správanie atribútu je korektné, to ale neplatí pre ASP.NET.

Pri vysokej záťaži ASP.NET a rôznej časovej náročnosti spracovávaných funkcií sa môže stať, že príliš veľa I/O threadov spracováva requesty. ASP.NET potom zastaví spracovávanie requestu, odloží ho niekam do fronty, a príslušný thread bude pracovať na ďalšom requeste. Časom je request opať na rade a priradí sa mu nejaký dostupný worker thread. (poznámka: do hĺbky spracovania requestov I/O threadmi nevidím, možno by niekto v diskusii mohol ozrejmiť a lepšie konkretizovať túto časť a spojenie I/O threadov a worker threadov).

Ale späť k téme. Pri migrovaní requestu medzi threadmi nepremigruje všetko, ako by si niekto mohol myslieť, ale iba HttpContext. Dáta uložené napríklad v CallContext sú fuč. Keď už je nám známe migrovanie threadov, pri použití [ThreadStatic] nastáva jeden základný problém: ThreadStatic fieldy sú privátne a lokálne zdieľané medzi threadmi (t.j. vždy iba jeden z threadov pristupuje k dátam). Pri migrovaní sa môže ľahko stať, že iný thread dostane dáta niekoho iného. Riešením je použitie niečoho, čo je naozaj privátne a lokálne, ale vzhľadom na request. Odpoveď už zaznela - je to HttpContext. Kontext migruje medzi threadmi aj so všetkými dátami.

Veľmi pekným a odporúčaným miestom pre ukladanie dát v rámci jedného HTTP requestu je HttpContext.Current.Items. Tento objekt implementuje interfejs IDictionary, a teda ponúka elegantný prístup k dátam vo forme kľúč – hodnota. Pekné miesto na uloženie singletonov. A poďme rovno na príklad, jemne modifikovaný singleton č.2:

public class MojSingleton
{
      private MojSingleton ()
      {
      }

      private static readonly object padlock = new object();

      private static readonly string CONTEXT_ITEMS_KEY = "__MojSingleton";

      public static MojSingleton oInstance
      {
          get
          {
              lock (padlock)
              {
                  if (HttpContext.Current.Items[CONTEXT_ITEMS_KEY] == null)
                      HttpContext.Current.Items[CONTEXT_ITEMS_KEY] = new MojSingleton ();
                  return (MojSingleton)HttpContext.Current.Items[CONTEXT_ITEMS_KEY];
              }
          }
      }
}

Výhody a nevýhody. Singleton je naozaj thread-safe, dáta prežijú počas celého requestu a po ukončení je inštancia pekne odprataná z pamäte -- automaticky. Ostatné controly môžu využívať funkcie a dáta inštancie triedy a inštancia sa vytvára až vtedy, ak je potrebná. Ak potrebujete uložiť dáta medzi requestami, použite objekt Session, vid. príklad č.2. Alebo ak volanie konštruktora je drahé a uložené miesto v Session naopak. Nevýhodou je, že nižšie vrstvy vašej aplikácie musia referencovat namespace System.Web, aby mohli pristupovať k property HttpContext.Current. V prípade väčších a zložitejších aplikácií to nemusí byť dobré a žiadúce, ak napríklad plánujete neskôr použiť spodné vrstvy aplikácie pre winforms alebo console projekty. Veľa programátorov potom pristupuje priamo k threadu a ukladá dáta na nejaké storage miesto spojené s threadom, v snahe vyhnúť sa úzkej napojenosti na webové prostredie. Tento prístup však nebude fungovat v prípade ASP.NET, veriť možno iba HttpContext-tu.

A čo s [ThreadStatic] ? Nie je to nepoužiteľný atribút, avšak v ASP.NET aplikáciach by sa mal používať opatrne. Nezabudnúť, že request može byť spracovaný rôznymi threadmi počas svojho krátkeho života. Preto ukladanie dát v takomto fielde je zlým riešením. Ak však trieda, singleton, obsahuje iba metódy a žiaden stav (dáta), bude jeho použitie bezproblémové. (-: až do chvíle, keď zabudneme na ThreadStatic a pridáme do triedy nejaké data :-)

Uvítam, ak do diskusie prispejete aj svojimi poznatkami, prípadne dodatočným vysvetlením. Ak na niektorom mieste píšem nesprávne, napíšte mi a text opravím, resp. doplním. Vďaka a do threadovania.

Update: tento (jediný) príspevok som uverejnil na svojom predchádzajúcom blogu, no nakoľko je server už dlhú dobu mimo provoz, rozhodol som sa presunúť na tento portál, kde už nejaký ten čas pôsobím (pozdravujem fórum). Dúfam, že to tu vydrží dlhšie :-)