K tomu RC a k pomalosti přičítání. Opět tu vidím problém v tom, že to někdo řeší na úrovni systému. Já třeba RC implementuju zásadně jako MT unsafe, právě kvůli tomu, že InterlockedIncrement a InterlockedDecrement stojí nějaký nemalý výkon. Programátor má také k dispozici i MT Safe varianty, ale ty musí specifikovat explicitně. Přepínání mezi MT Safe a MT Unsafe přitom řeší pointer, nikoliv vlastní objekt, takže výběr správného pointeru je podle použití.
Používání MT Unsafe má hlavní smysl v tom, že sdílení objektů mezi vlákny zas není tak časté. Velice častěji má objekt, nebo objektovou strukturu na starost jedno vlákno, ostatní jen do něj přistupují a ti použivají klasické pointery. U objektů, které se umí klonovat (a u RC-Stringů) pak existuje metoda isolate(), která provádí fork objektu, pokud má ref.count větší než jedna. To je právě určeno pro vlákna, kde se simuluje takový malý fork objektu. Pak už MT Safe countery nemají smysl.
Stejně tak většina mých alokátorů je MT Unsafe, právě proto, že se počítá, že každé vlákno bude mít vlastní instanci. Mám změřeno, že výkon takových aplikací, třeba na mapách, spojových seznamech a podobně , je výrazně vyšší, než klasické STL + malloc
ČLÁNKY DO MAILU