Odpověď na názor

[16] Instrukce Lock má obrovský overhead na víceprocesorových systémech. Řádově tak 100x pomalější běh, než když je INC bez LOCKu. Příkaz InterlockedIn­crement navíc bývá právě implementován jako LOCK INC []

[15] Tak a teď vám to celé vyvrátím levou zadní.

1) Ano, programátor to musí rozhodnout. Kdo by to měl rozhodovat? Valná většina čítačů se konstruuje jako ST a jen v případě, že objekt musím sdílet do jiného vlákna stačí pointeru nastavit MT. Na to mám funkci getMT(), která vrací this, ale vynuluje nejvyšší bit.

2) To si děláte legraci. Z principu nelze vytvořit tolik referencí, protože každý pointer zabere 4 bajty. Takže i kdybych obsadil každou čtveřici referencí, nikdy se mi to číslo nepřeklopí

3) U intruzivního čítání je to nutné, jinak byste pracoval s counterem na adrese NULL, která není přístupná. Jo už jsem uvažoval, že bych jako NULL dal ukazatel na nějaký plonkový čítač, který by citani NULL referencí umožňoval. O intruzovní čítání v tomoto článku jde především

4) Kód vypadl z optimalizátoru MSVC. Je to po aplikaci /O3 a po inlinování těchto bloků do kódu. Jsou tedy vždycky optimalizované svému okolí. Tatáž část tedy vypadá v různých částech kódu různě. Proto třeba se do EBX ukládá adresa na InterlockedIn­crement, která se používá vícekrát. Zdánlivé neoptimality vychází z toho, že některé instrukce lze zpracovávat superskalárně, jiné nelze a tak je někdy opis rychlejší, než kratší zápis

Přičtení jedničky u vícejádrových procesorů není bezpečné! U takových čtyřjader je opravdu potřeba použít instrukci LOCK, což je vlastně InterlockedIn­crement. Instrukce LOCK znamená serializaci instrukcí, flush instrukční cache, zámek sběrnice, tím pádem zdržení o ostatních procesorů. Dále se flushuje zápisová cache, čtecí cache, a to všechno jen proto, aby se někde přičetla jednička. I nepodařený odhad skoku zabere méně taktů, než LOCK. LOCK je příšerně drahá.