[17]: Pane, LOCK INC by nebyl schopen splnit požadavky InterlockedIncrement. Když se podíváte na dokumentaci této funkci, tato funkce kromě přičtení musí ještě vrátit předchozí hodnotu. A to pomocí LOCK INC není schopna. A pokud jí načte později, tak vzhledem k multithreadovému prostředí mohla být mezitím změněna.
Takže ano, aniž bych znal jak to MS provádí, tak sotva to bude implementováno pomocí LOCK INC.
Nehledě na to, že INC instrukci skutečný programátor nepoužívá, protože je neefektivní sama o sobě. Je špatně optimalizovaná v procesorech a díky tomu, že nastavuje příznaky odlišně než většina jiných instrukcí způsobuje dodatečná zpoždění v procesoru, protože potřebuje extra čas na vyřízení této odlišnosti.
Ale uznávám, v době Windows 95 musela InterlockedIncrement používat LOCK INC, protože na 386 procesoru jiná možnost nebyla. Návratovou hodnotu pak musela odhadnout z příznaků. Ale už na 486 procesoru jsou k dispozici mnohem lepší instrukce, které hodnotu vrátí přímo.
Protože v Microsoft Visual C/C++ trochu dělám, tak si tipnu, že takovou neoptimalitu, jako je trojice instrukcí za MT částí tento kompilátor neprovede. Stejně tak takovou hovadinu, že by použil instrukci INC.
Takže buď používáte verzi kompilátoru z muzea, nebo jste nastavil optimalizaci špatně. MSVC optimalizuje velmi dobře a jeho asm výpisy jsem mnohokrát viděl. Dokonce jsem je občas používal i na studium, jak dobře psát v asm, než jsem došel dál, než jsou schopnosti automatického kompilátoru.
Ad 1) Programátor to ale nemůže rozhodnout. Princip shared_ptr je, že se sdílí data na více místech. Občas ani nemůžete tušit, kam všude se dostane. Jen v případě, že rozkopírujete proměnnou po x místech ve stejném threadu lze nebrat multithreading v úvahu.
Čítač je velmi často v objektech, kde se používá copy on write (COW), a programátor to často ani nemusí vědět. Respektive je naprosto zbytečné ho tím otravovat.
A znovu říkám. Stačí JEDINÁ chyba v rozhodnutí programátora, že nějaký čítač není multithreading a celé, zdůrazňuji celé to letí do kopru. Čas od času, velmi zřídka, to prostě zkolabuje, chyba je těžko opakovatelná a téměř se nedá nasimulovat ani předvést.
Toto rozhodování bude vést k tomu, že programy začnou být méně spolehlivé a nedá se to v zásadě dost dobře otestovat. A velmi těžko se na to přichází.
Ad 2) Pokud předpokládáte, že vyrábíte pouze nezchybné programy, pak máte pravdu.
Ad 4) To už je naprostá hovadina. Vím, jak procesor optimalizuje a tyhle neoptimality rozhodně kromě zdržování k ničemu nepřispějí. Ostatně ty 3 instrukce co jsem dal za příklad, nebo instrukce inc není nic, co by kromě zhoršení dělalo něco jiného.
LOCK především může znamenat naprosto cokoli. Je to implementačně závislé a procesor se snaží LOCK instrukci zoptimalizovat. LOCK nenutí procesor k serializaci všech instrukcí, pouze k serializaci přístupů na jeden kousek paměti. Procesor to ví.
Jestli dovolíte, nemám už chuť na Vás reagovat. Jste velmi sebevědomý a nelámete si hlavu s pravdivostí Vašich argumentů. Mohl bych stejně tak reagovat na zbytek, ale odpustím si to.
ČLÁNKY DO MAILU