Jaderné noviny – 2. 2. 2012: Co se v Linuxu 2.6.39 stalo s diskovým výkonem

13. 2. 2012 | Luboš Doležel | Jaderné noviny | 5359×

Aktuální verze jádra: 3.3-rc2. Citáty týdne: Steven Rostedt, Linus Torvalds, Ted Ts'o, Dave Chinner. Greg Kroah-Hartmann přechází k Linux Foundation. Co se v Linuxu 2.6.39 stalo s diskovým výkonem. Zrada bitového pole.

Obsah

• Aktuální verze jádra: 3.3-rc2
• Citáty týdne: Steven Rostedt, Linus Torvalds, Ted Ts'o, Dave Chinner
• Greg Kroah-Hartmann přechází k Linux Foundation
• Co se v Linuxu 2.6.39 stalo s diskovým výkonem
• Zrada bitového pole

Aktuální verze jádra: 3.3-rc2

Aktuální vývojová verze jádra je 3.3-rc2 vydaná 31. ledna – což je o trochu později, než se čekalo. Diffstat je dost rovnoměrný – což značí, že jsou tam především rozprostřeny malé změny. To vidím rád a bohužel to v této fázi tak vždy není. Přesouvají se tam nějaké soubory (sériový port na bázi 8250 a sloučení mx5 -> imx v arm), jinak nic moc zajímavého. To je fajn. Přesto je v této předverzi docela dost změn, krátký seznam změn naleznete v oznámení. Třináct z těchto změn odstraňuje patche, které se nevyvedly.

Stabilní aktualizace: za poslední týden žádné nevyšly. Verze 2.6.32.56, 3.0.19 a 3.2.3 jsou aktuálně ve fázi revidování; můžeme je očekávat 3. února nebo později.

Citáty týdne: Steven Rostedt, Linus Torvalds, Ted Ts'o, Dave Chinner

Nebylo by to poprvé, kdy lockdep a ftrace způsobí livelock systému. Nebo jej neskutečně zpomalí. Lockdep a ftrace spolu moc dobře nefungují. Oba jsou dost vlezlé. Připomínají mi americký kongres. Tam se dvě strany snaží nad vším získat moc, ale ve výsledku neodvedou žádnou práci. Výsledkem je grid/live lock v počítači/zemi.

-- Steven Rostedt

Dovedu si představit, že by to bylo dílo pomstychtivého programátora, který si řekl „Teď to těm lidem, co upozornili na chybu v mém kódu, natřu, hahahahahahaha! Opravím to tak, aby test case prošel, ale podstaty problému se nedotknu,“ ale nemyslím si, že by lidé od kompilátorů byli *tak* zlí. Ano, jsou to zlí lidé, co se nás snaží napálit, ale i tak.

-- Linus Torvalds

V tomto směru je můj přístup k ext4 takový, že ext4 by mělo být jako linuxové jádro; je to evoluční proces a centrální plánování je často přeceňované. Lidé přispívají do ext4 z mnoha různých důvodů a to znamená, že optimalizují ext4 pro své vlastní využití. Stejně jako Linus s Linuxem se nesnažíme navrhovat věci s cílem „ovládnout svět“ tím, že bychom říkali, „hmm, raději implementujeme funkce A a B, abychom 'odrovnali' reiserfs4“.

-- Ted Ts'o

Stavíte na předpokladu, že uživatelé jsou znalí a dobře informovaní, ale všichni vývojáři souborových systémů by měli vědět, že to prostě není pravda. Uživatelé neustále dokazují, že nevědí, jak souborový systém funguje, nerozumí nabízeným volbám, nerozumí tomu, co jejich aplikace z hlediska operací nad soubory dělají, a opravdu nerozumí svým datům. Vzdělání vyžaduje čas a píli, ale uživatelé přesto dělají stejné chyby dokola.

-- Dave Chinner

Vypadá to, že v release kódu drm je víc draků a padacích dveří, než je tam řádek.

-- Daniel Vetter

Greg Kroah-Hartmann přechází k Linux Foundation

Linux Foundation oznámila, že se Greg Kroah-Hartmann připojil k jejich týmu. Na své pozici v Linux Foundation bude Kroah-Hartmann pokračovat v práci správce stabilní větve Linuxu a řady subsystémů, zatímco bude pracovat v plně neutrálním prostředí. Bude také úzce spolupracovat se členy, pracovními skupinami, projekty v Labu a personálem Linux Foundation na důležitých iniciativách s cílem posunout Linux dál.

Co se v Linuxu 2.6.39 stalo s diskovým výkonem

Herbert Poetzl nedávno nahlásil zajímavý výkonnostní problém. Jeho laptop s SSD diskem dokázal pod jádrem 2.6.38 číst data o rychlosti kolem 250 MB/s , ale výkon spadl na 25-50 MB/s na všech novějších jádrech. Pád výkonu o jeden řád není ten typ novinky, na který se lidé těší při aktualizaci jádra, takže hlášení si hned získalo pozornost řady vývojářů. Řešení problému se ukázalo být jednoduché, ale přináší zajímavý pohled na to, jak diskové I/O v jádře funguje.

K vysvětlení problému je zapotřebí jen trocha teorie, zejména pak definice pár pojmů. „Readahead“ je proces, kdy je soubor spekulativně načítán do paměti na základě předpokladu, že aplikace tato data bude brzy chtít. Rozumný výkon při sekvenčním čtení souboru závisí na dobře udělaném readahead; je to jediný způsob, jak zajistit to, že čtení a zpracování dat bude probíhat paralelně. Bez readahead budou aplikace čekat na přečtení dat z disku víc, než je nutné.

"Plugging" je zase proces zastavení zasílání I/O požadavků nízkoúrovňovému zařízení po určitou dobu. Smyslem pluggingu je umožnit nahromadění určitého množství I/O požadavků, aby je plánovač I/O mohl seřadit a aby sloučil přilehlé požadavky a uplatnil jakákoliv nastavená pravidla férovosti. Bez pluggingu by I/O požadavky byly menší a byly by více roztříštěné napříč diskem, což by výkon snižovalo dokonce i na SSD.

Teď si představte, že máme proces, který se chystá číst z dlouhého souboru, jak je naznačeno na tomto obrázku.

Jakmile aplikace začne číst ze začátku souboru, jádro začne s naplňováním prvního readahead okénka (které má u větších souborů 128 KB) a zařadí požadavek pro druhé okénko, takže situace bude vypadat nějak takhle:

Jakmile se aplikace dostane za 128 KB, data, která potřebuje, už snad budou v paměti. Mašinérie kolem readahead se zase spustí a spustí se i I/O pro okénko od pozice 256 KB; výsledkem je situace na následujícím obrázku:

Tento proces pokračuje donekonečna, jádro má vždy náskok před aplikací a má data v době, kdy se aplikace dostane k jejich čtení.

V jádře 2.6.39 došlo k výrazným změnám v tom, jak se plugging dělá, s tím výsledkem, že plugging a opětovné uvolnění je nyní explicitně řízeno v kódu, kde se zadávají I/O požadavky. Takže od verze 2.6.39 kód pro readahead zastaví frontu požadavků před zařazením dávky operací a pak zase frontu odblokuje. Funkce, která řídí základní bufferované I/O nad soubory (generic_file_aio_read()), nyní dělá své vlastní zastavování. A zde celý problém začíná.

Představte si, že proces čte po velkých (1 MB) blocích. První velké čtení skončí v generic_file_aio_read, tato funkce zastaví frontu požadavků a začne procházet stránky souboru, které už jsou v paměti. Jakmile se dostane na konec prvního přednačítaného okénka (na 128 KB), kód pro readahead je spuštěn, jako je popsáno výše. Ale je tu problém: fronta je stále zastavena funkcí generic_file_aio_read(), která stále zpracovává požadavek na 1 MB, takže I/O operace zadané ke zpracování kódem pro readahead nejsou předány hardwaru; jen čekají ve frontě.

Takže jakmile se aplikace dostane ke druhému okénku pro readahead, dostaneme se do takovéto situace:

V tento moment se všechno zastaví. To povede k odblokování fronty, což konečně umožní provedení I/O požadavků pro readahead, ale to je příliš pozdě. Aplikace bude muset čekat. Toto čekání stačí k tomu, aby se výkon propadl, a to i na SSD.

Oprava spočívá v odstranění zastavování na nejvyšší úrovni v generic_file_aio_read, takže požadavky od kódu pro readahead se mohou dostat k hardwaru. Vývojáři, kterým se podařilo problém reprodukovat, hlásí, že patch problém odstraňuje, takže můžeme věc považovat za vyřešenou. Oprava by se brzy měla objevit v nějakém stabilním vydání.

Zrada bitového pole

Vývojáři mají z chyb kompilátorů strach a mají pro to důvod: takové chyby může být těžké odhalit i se jim pak vyhnout. Mohou v kódu ponechat skryté pasti, do kterých uživatelé spadnou v nevhodný okamžik. Věci se mohou ještě více zkomplikovat, jakmile je chyba vnímána vývojáři kompilátoru jako vlastnost – takové problémy nemusejí být nikdy vyřešeny. Je možné, že se právě tento typ vlastnosti objevil v GCC, dopad na jádro není znám.

Jedna z mnoha struktur používaných souborovým systémem btrfs – definovaná v fs/btrfs/ctree.h – vypadá takto:

struct btrfs_block_rsv {
	u64 size;
	u64 reserved;
	struct btrfs_space_info *space_info;
	spinlock_t lock;
	unsigned int full:1;
};

Jan Kára nedávno nahlásil, že pole lock je na architektuře ia64 občasně přepisováno. Trocha zkoumání vedla k tomu, že GCC dělalo při změně bitového pole full překvapivou věc: generuje 64bitový cyklus načíst-změnit-zapsat, při kterém dochází ke čtení lock i full, změně full a zápisu obou hodnot zpět do paměti. Pokud bylo lock během této operace upraveno jiným procesorem, tato změna bude ztracena při zpětném zápisu lock. To nevěstí nic dobrého.

Člověk si dokáže představit, že odhalit podstatu problému byla docela fuška. A asi nebude ani těžké si představit zděšení, k jakému vedl následující rozhovor:

Řekl jsem o problému lidem z GCC a řekli mi, že: "C takovou věc nezaručuje a stejně tak nemůžete spolehlivě zamykat různá pole struktury pomocí různých zámků, pokud sdílejí standardně zarovnaný [aligned] paměťový region o velikosti slova. Paměťový model C++11 toto zaručuje, ale ten není implementován a stejně k sestavování jádra nepoužíváte kompilátor C++11."

Není divu, že Linus touto odpovědí nebyl potěšen. Řekl, že standardy jazyků nejsou psány na míru jádrům a nemohou zaručovat, že chování bude odpovídat potřebám jádra:

C/gcc v tomto smyslu nikdy nic „neslibovalo“ a vždy jsme jen předpokládali, jaký kód je rozumné generovat. Většinou jsou naše předpoklady správné, a to proto, že by bylo od C kompilátoru *hloupé*, aby dělal něco jiného, než předpokládáme.

Ale někdy to kompilátory dělají. Používat 8bajtové přístupy k 4bajtové entitě je *hloupé*, když to ani není rychlejší a základní typ byl stanoven jako 4bajtový!

Jak už to bývá, problém je ještě rozsáhlejší. Linus navrhl spustit test s takovouto strukturou:

struct example {
	volatile int a;
	int b:1;
};

Pokud v tomto případě přiřazení do b způsobí zápis to a, tak je takové chování rozhodně chybné; klíčové slovo volatile stanovuje, že k adrese může být přistupováno odjinud. Jiří Kosina to zkusil a oznámil, že GCC i v tomto případě generuje 64bitové operace. Takže i když je původní chování technicky správně, je to pravděpodobně důsledkem toho samého rozhodnutí, které způsobuje chybu u druhého příkladu.

Tato věc může vývojářům jistě dodat výzbroj do hádek s vývojáři GCC, ale nemusí to nutně pomoci. Bez ohledu na zdroj problému toto chování může existovat ve verzích kompilátoru, které jsou mimo komunitu vývojářů používány k sestavování jádra. Může být proto nutné přijít s obezličkou, i když bude chování GCC opraveno. To může být docela výzva; auditování celého jádra s cílem najít 32bitová bitová pole ve strukturách, ke kterým může být přistupováno souběžně, to nebude jen tak. Ale nikdo ani neříkal, že je vývoj jádra hračka.

       

Komentáře

[eMan]

No, mě by spíš zajímalo, proč v Ubuntu 12.04 (alpha 2) dochází k uspávání a probouzení disku několikrát za minutu... Nevíte o tom někdo něco? Jak tomu zabránit? Roztáčení ploten hrozně žere baterii.

[kralyk z abclinuxu]

To na 99% nebude v jádře, spíš nějaká blbá power-saving konfigurace. Zkus tohle.

[eMan]

Děkuji za radu, zkusil jsem to podle návodu, tak se to snad umoudří.

[branchman]

To uz je tam najmenej od casov 10.04 - viz Bug #607560 o prebudzani disku

[Dreit]

Myslim že jsem na tom byl podobně - disk jede cca 5 vteřin, pak zastaví a jakmile se dotočí, tak se roztáčí znova. Dělal mi to novej netbook hned po instalaci Debianu, stačilo vypátrat příkaz co to zakáže....píšu z mobilu, tak můžu jen odkázat na "Linuxtero" na Ubuntí Wiki, stačí dát na stránce hledat hdparm a někde tam ten příkaz je

[JoHnY2]

To s tim polem zni vazne hodne strasidelne.

[frr]

To myslej lidi od GCC vážně?

[whata]

Mno, je to sice v tomto případě zarážející a hlavně zbytečné, na druhé straně jsou ale architektury a paměťové velikosti, kde nemají na výběr. Pokud mě neklame paměť, například Alpha umí pracovat pouze s 8bit, 32bit a 64bit, starší verze snad neuměly ani ten 8bit. Řešení je buď použít load/store exclusive, což je dost drahé, nebo říct, že kompilátor se chová v takových situacích nepředvídatelně, což gcc-isti udělali ;) Asi budou potřebovat nový atribute, něco jako "separate"...

[zxtlpn]

On ten standard C vážně nic moc extra nezaručuje.

[Kvakor]

Ano, v C standardu jsou situace, kde není přesně definováno, co má překladač udělat, tudíž se může chovat i podivným a nepředvídatelným způsobem. Viz nasal demons

[Martin Mareš]

No minimálně pro volatile to zaručuje dosti konkrétně a GCC porušuje i to.

[Sten]

To se řeší tak, že se udělá align tak, aby to fungovalo (samozřejmě taková struktura nesmí být packed, ale v takovém případě může kompilátor zařvat). Jak myslíte, že to dělá to C++11?

[whata]

aligned je taky možnost, ale za prvé zbytečný kanón na vrabce (zarovnal by na 64-bitů, když to není třeba), za druhé nabourá binární kompatibilitu (což v případě jádra není problém).

volatile taky není ideální, bo nevystihuje skutečný problém. Takže za separate si stojím

Zvláštní ale je, že se mi to nedaří reprodukovat, zkouším gcc 4.4, 4.5, 4.6. Asi specifické pro ia64...

[Sten]

Proč by volatile nebyl vhodný? IMO je přesně na tohle. Pokud to čte a zapisuje jenom jedno vlákno, tak je jedno, že to čte/zapisuje víc, než čekáte. A pokud to čte/zapisuje více vláken, mělo by to být volatile, jinak vám to klidně může kompilátor zoptimalizovat tak, že změní doby, kdy se čte/zapisuje, případně bude číst jenom jednou nebo zapisovat jenom na konci.

[Luboš Doležel (Doli)]

Dávat volatile na jednu proměnnou, aby nebyly problémy s druhou, to je trochu bordel, ne?

[Sten]

Ale ony nejsou problémy s tím bitem, ale s tím zámkem, který se odemyká, když nemá, protože při změně toho bitu kód přepisuje i ten zámek, a tedy by měl být volatilní.

[little.owl]

Ano, v pripade bez volatile na locku se to chova podle standardu (nespecifikovano), ale pokud je na locku volatile, kompilator nemuze provadet [neatomicke] operace menici obsah volatile promene.

Nastesti tyhle konstrukce jsou v automotive/industrial/medical aplikacich vetsinou ilegalni :-/

[Filip Jirsák]

Ano, v pripade bez volatile na locku se to chova podle standardu (nespecifikovano)

V tom případě je ale chování podle standardu i to, když by vygenerovaný kód změnil hodnotu v paměti úplně někde jinde, a před dokončením dané "instrukce" by ji zase vrátil zpět. Takhle to sice nemusí dávat smysl, ale stačilo by třeba mít dvě nezarovnané struktury za sebou:

struct btrfs_block_rsv1 {
	u64 size;
	u64 reserved;
	struct btrfs_space_info *space_info;
	spinlock_t lock;
};
struct btrfs_block_rsv2 {
	unsigned int full:1;
};

Tohle by přece také mohl kompilátor podle standardu přeložit úplně stejně, tj. načte z paměti lock i full, změní full a zapíše obojí zpět. Podle mne by se pak ale v C vůbec nedaly programovat vícevláknové aplikace, protože pokud se nepoužijí zámky znamenalo by to, že kód jednoho vlákna může v paměti změnit úplně cokoli, pokud to před dokončení "instrukce" vrátí zpátky. Jenže jiné vlákno může kdykoli narazit na ta změněná data…

[little.owl]

Ne. Ne. Ne.

Ten priklad je nesmysl, cinite plno predpokladu, ktere nejsou z duvodu portability v C garantovany a nejenom u pakovani struktur, ale i u umisteni pameti a pristupu do pameti.

Cele to tu prameni z toho, ze se nebere v potaz nebo nezna C standard, zejmena jeho cast, ktere specifikuje bit-fields ve strukturach.

Budu citovat jednu cast z ISO C:

An implementation may allocate any addressable storage unit large enough to hold a bitfield. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit. If insufficient space remains, whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is implementation-defined. The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined. The alignment of the addressable storage unit is unspecified.

Ma to racionalni zaklad a zejmena v kontextu mozneho pristupu do pameti specifickeho pro dany HW - a C je zde musi byt velmi volny - i plno konsekvenci.

Treba pokud mate strukturu

struct test {
	unsigned aa:1;
	unsigned bb:2;
	unsigned cc:1;
}

tak sizeof(struct test) muze byt vetsi nez 1; a zaroven aa, bb and cc jsou ve stejnem bytu; pokud predpokladate vice dostavate se do zavislosti na architekture, implementaci a zavadite nekonzistentni pozadavky.

[Sten]

Ty struktury ale budou zarovnané, to by musely být v další struktuře, která bude packed.

[Filip Jirsák]

Na tom ale přece nezáleží, to jsem zmínil jenom pro to, abych uvedl nějaký případ, kdy by takové chování kompilátoru mělo zřejmou logiku. Podstatné je, že podle této interpretace standardu může kompilátor vygenerovat kód, který změní libovolnou část paměti, pokud to v tom samém vlákně následně zase dá do pořádku. Jenže s takovým přístupem se nedá naprogramovat nic vícevláknového.

[little.owl]

Podstatné je, že podle této interpretace standardu může kompilátor vygenerovat kód, který změní libovolnou část paměti,

To je totalne nesmyslne tvrzeni.

Muze to udelat jenom v chybne napsane aplikaci, ktera stavi na nespecifikovanych nebo implementacne zavislych vecech. C standard je v tomto dobre promyslen a i celkem jasny - viz ma citace nahore.

Jenže s takovým přístupem se nedá naprogramovat nic vícevláknového.

Opet musim odmitnout. Lze psat vicevlaknove aplikace a pritom respektovat standard, nekdy je to i vyzadovane - treba automotive ci medical firmware. Nekdy je sice vyhodne z hlediska vykonu a efektivity to nerespektovat a spolehat na implementacni detaily kompilatoru a cilove platformy, ale ma to svou cenu.

[Filip Jirsák]

Ta citace nahoře neříká nic o tom, že při operacích s tou datovou strukturou nesmí vygenerovaný program sahat nikam jinam. Tohle je věc, na kterou se celou dobu ptám. Argumentuje se tím, že specifikace nezakazuje kompilátoru přečíst a zapsat i sousední bitová pole, určuje jen požadovaný výsledek v jednovláknovém programu. Tak se ptám, kde ve specifikaci je ten zákaz pro jiné případy.

[kralyk z abclinuxu]

Ta citace nahoře neříká nic o tom, že při operacích s tou datovou strukturou nesmí vygenerovaný program sahat nikam jinam.

Proč by měl někam jinam - mimo tu strukturu - sahat? K tomu přece není žádný důvod. Tady se jedná o práci s pamětí pozue v rámci té struktury.

Jinak ale standard to asi nezakazuje, stejně jako nezakazuje vždy v úplňkovou noc vygenerovat náhodné číslo a poslat ho po síti do kerosenem poháněného struhadla na sýr.

[Filip Jirsák]

Úplně to samé – že k tomu není žádný důvod – si mysleli vývojáři jádra i o té struktuře s bitovými poli. Programátoři GCC důvod našli, a protože jim to standard nezakazuje, tak ve struktuře s bitovým polem jinam sahají. Takže se ptám, jestli zase mají vývojáři jádra spoléhat na to, že podle nich není důvod, a čekat, až jim vývojáři GCC ukážou, že důvod je, a bude z toho zase nějaká pěkná chyba.

[little.owl]

Ale, ale, no tak.

Puvodni konstrukce bez volatile je chyba v kodu kernelu (spolehani se na implementation-defined/unspecified behaviour); druha konstrukce s volatile je bug na strane gcc.

A kdo je ted ten bad guy?

[Filip Jirsák]

spolehani se na implementation-defined/unspecified behaviour

Dobře. A kde je tedy ta hranice, co je už definováno standardem? Když budu spoléhat na to, že to GCC nebude dělat s bajtem a 32bitovým slovem (pro změnu bajtu přečte okolní 32bitové slovo, změní bajt a zapíše zpět slovo), má to spoléhání oporu ve standardu, nebo je to zase spoléhání na implementation-defined/unspecified behaviour?

[little.owl]

Ne, ne. Problem neni ve cteni/zapisovani dat, ale v tom ze pristup k bitum v bit-fields zapakovanych ve strukture neni by default atomicky a ani diskretni, nehlede k tomu ze implementace kompilatoru ma velkou volnost jak bity v pameti ulozit.

[Filip Jirsák]

To už sem tady četl asi desetkrát a desetkrát jsem se na to zeptal, kde je ve specifikaci napsáno, že přístup třeba k bajtům nebo 32bitovým slovům zapakovaným ve struktuře atomický a diskrétní je.

[little.owl]

Standard specifikuje co je minimalni adresovatelna jednotka a definuje typ sig_atomic_t, u nehoz je atomicita zarucena.

Jestlize minimalni adresovatelna jednotka ma 8 bitu, jak chcete atomicky modifikovat tri bity u zapakovane struktury?

Jestlize ma sig_atomic_t 8 bitu, jak chcete atomicky modifikovat 16 bitu?

[alkoholik]

Pan se celou dobu pta, jestli nahodou prekladac nedela to same s byty/wordy/dwordy. Neco jako: Vlakno A chce cist byte, ale precte se ve skutecnosti cely word.
Vlakno B prepise druhy byte z toho wordu.
Vlakno A zapise zpatky cely word s puvodni hodnoutou druheho bytu, takze vlaknu B prepise vysledek.

[little.owl]

Od toho je alignment.

[Filip Jirsák]

Alignment je věc, kterou kompilátor může použít. Ale já se celou dobu ptám, zda standard omezuje hranice, přes které kompilátor jít nesmí. Zatím jsem se od vás dozvěděl, že bitové pole ani položky ve struktuře tou hranicí nejsou. Takže ta hranice možná leží ještě dál, a možná ve standardu vůbec není.

[little.owl]

Alignment je věc, kterou kompilátor může použít.

Nekdy muze z duvodu vykonu, nekdy musi z duvodu architektury HW.

Ale já se celou dobu ptám, zda standard omezuje hranice, přes které kompilátor jít nesmí.

Hranice v cem?

POD data (char, int etc.) jsou zpracovavana korektne, jak se pracuje se strukturami a bit-fields je take specifikovano.

[kralyk z abclinuxu]

Takže ta hranice možná leží ještě dál, a možná ve standardu vůbec není.

Tomu bych se vůbec nedivil (#34), ale co se na tom snažíš celou dobu dokázat? Že standard neobsahuje dlouhý seznam všech možných i nemožných kravin, které by teoreticky kompilátor mohl udělat? Mně by překvapilo, kdyby to tak bylo.

Co se multithreadingu a synchronizace týče, tyhle věci adresuje až nejnovější, několikrát zmiňovaný standard C11, tak proč se nekoukneš na něj?

[Filip Jirsák]

"Změna hodnoty proměnné nesmí mít vedlejší efekt ani ve vícevláknovém prostředí" je dlouhý seznam? Jak se ukázalo, některé ty kraviny kompilátor prakticky dělá, a jeho autoři to obhajují právě tvrzením, že je to v souladu se specifikací. Takže ano, mělo by to být ve standardu, protože když to tam není, někdo toho zneužije. A když to není ve standardu, má to tvůrce kompilátoru napsat do specifikace kompilátoru, která přidává další garance nad rámec standardu. Protože bez takové garance někdo do toho kompilátoru tu kravinu naprogramuje, a kompilátor, který dělá kraviny, se nepoužívá moc dobře.

Co se multithreadingu a synchronizace týče, tyhle věci adresuje až nejnovější, několikrát zmiňovaný standard C11, tak proč se nekoukneš na něj?

Protože se tady řeší starší verze standardu. A protože programovat vícevláknové aplikace nejde v jazyce, kde platí, že libovolný kód může mít ve vícevláknovém prostředí libovolné vedlejší důsledky.

Ono sice platí, že v běžných programovacích jazycích musí programátor zapomenout na spoustu předpokladů, které jsou při jednovláknovém programování splněné. Ale zároveň platí, že pro aspoň trochu rozumné vícevláknové programování musí být spousta dalších předpokladů splněna. A to, že programátor musí vždy přesně vědět, která operace změní která data, je zrovna jeden z těch požadavků, které nelze vynechat.

[kralyk z abclinuxu]

Já fakt absolutně nerozumim, o co ti jde. Standard byl aktualizován a Martin Mareš píše, že lidi od GCC přiznávají bug. Navíc GCC již ve verzi 4.6 obsahuje prvotní omezenou podporu C11, 4.7 přidává další featury [zdroj] a plná podpora je snad v TODO pro 4.8 (tohle nevím jistě), takže se dá celkem očekávat, že GCC dřív nebo později C11 podporovat bude.

Co bys ještě chtěl dalšího?

[pc2005]

Teď už jen přepsat kernel do nové verze .

[little.owl]

Kernel by spise potreboval svuj vlastni standard, obcas se divim lidem od GCC, ze je nekopnou nekam.

[Martin Mareš]

Kernel (nebo libovolný jiný kus podobně nízkoúrovňového kódu, pokud má fungovat efektivně) prostě od překladače potřebuje daleko víc, než běžný uživatelský program. Lze to řešit buďto tím, že autoři kernelu počítají s tím, že překladač nebude vyvádět psí kusy, nebo zavedením hromady pomocných konstrukcí do jazyka, které překladači řeknou dostatečně jasně, co programátor chce. Pomalu konvergujeme od toho prvního modelu k tomu druhému, ale je jasné, že to bude trvat dlouho.

[little.owl]

Odhlednu od prvni vety, to vystihl dobre Kralyk.

Vy stale nechapete problem. Cela rada architektur nepodporuje instrukce s bitovou adresaci, nektere dokonce ani bitove manipulace a pak je jedine reseni nacist blok dat, nejak zpracovat a zapsat zpatky, a to vse neatomicky, o adresacnich modech a alignment ani nemluve. Proto nemuzete garantovat atomicke zpracovani bitu a zapackovani struktury najednou. Stavajici pozadavky ve standardu jsou minimalni prave proto, aby bylo mozne implementovat C kompilator temer pro cokoliv a zaroven bylo neco garantovano.

[Filip Jirsák]

Já problém chápu. Pokud nějaká architektura nepodporuje bitovou adresaci nebo bitové manipulace, nemusí na takové architektuře kompilátor komprimovat bitová pole do jednoho slova. Pokud platí, že standard to neřeší, tak si to kompilátor může dělat, jak chce – kde je pak ta hranice. A kde je napsaná. Může to kompilátor udělat pro sousední bitová pole? Podle lidí od GCC ano. Může to udělat pro sousední bajty v jednom slově? Může to udělat pro sousední prvky v poli? Obávám se totiž, že ta hranice nikde ve standardu není, takže "standard to neřeší, takže si to kompilátor může udělat, jak chce" lze použít na libovolně velkou oblast paměti. S čímž se dají dělat jen dvě věci – doufat, že takovou optimalizaci, kde by se ta hranice reálně posunula dál, hodně dlouho nikdo do GCC nepřidá; a nebo přestat s GCC kompilovat vícevláknové aplikace. Pka je tu ještě třetí, nejrozumnější možnost – lidi od GCC řeknou, že i když to standard neřeší a mohli by si tedy dělat, co je napadne, pro reálné použití ve vícevláknových aplikacích ta hranice někde musí být. Takže ji někde stanoví a budou ji dodržovat, i když je k tomu žádný standard nenutí.

[little.owl]

Ne, ne, ne.

Standard resi v podstate, vse co je potreba. Specifikuje jak je nakladano s bit-fields ulozenymi ve strukture. Specifikuje pametovy model jazyka C, jak jsou data ctena a zapisovana a je se naklada s klicovym slovem volatile.

Co chcete vice?

Snad vam to nekdo vysvetli lepe, uz si s vami nevim rady. Ja bych nemohl ucit, ja bych ty studenty mlatil.

[Filip Jirsák]

To by mne právě zajímalo, kde to v tom standardu je. Kde je napsáno, že při zápisu bitového pole může GCC vygenerovat kód, který načte a zapíše i okolní bity, a kde je napsáno, že v jiných případech takový kód kompilátor vygenerovat nemůže. Protože podle toho, co je v článku, soudím, že to ve standardu nikde není.

[little.owl]

Standard rika co kompilator musi implementovat, zbytek je v kategorii undefined, unspecified a implementation-defined behavior. Atomicky pristup k bitum zabalene struktury neni vyzadovan nebot podle standardu nejmensi adresovatelna jednotka je char. Zbytek je dusledek.

[Filip Jirsák]

Když kompilátor přeloží

struct test {
	char a;
	char b;
	char c;
	char d;
}
test.a = 0;
test.c = 0;
test.d = 0;

jako

get32
and32 0x00FF0000
set32

vyhovuje standardu?

[little.owl]

A to ma demonstrovat co?

Nemluvili jsme celou dobu o nahodou pakovanych bitovych polich a pristupu k nim?

Dukaz kompilatorem ?

O tom co je garantovano standardem, nikoliv platforme a implementacne zavisle?

[Filip Jirsák]

Klidně vám to přeložím: Je to, že to kompilátor takhle nesmí přeložit, garantováno standardem?

[little.owl]

Kompilator to muze prelozit jak chce, pokud splni zavazne requirements.

Krom toho, je to prelozeno dobre.

[Filip Jirsák]

No, konečně jsme se k něčemu dostali. Takže standard C jako takový je nepoužitelný pro drtivou většinu vícevláknových programů. Použitelný je jedině v případě, že kompilátor bude garantovat některé věci nad rámec standardu – bude tedy plně v souladu se standardem, ale dobrovolně se omezí víc. V případě GCC ta dobrovolná omezení zatím nebyla nikde specifikována a jádro (a spousta dalších programů) na ně spoléhá. Teď se v jádru narazilo na jeden případ, kdy měl každý jinou představu o tom, jak to dobrovolné omezení vlastně vypadá. Takže je asi na čase, aby lidé od GCC ta dobrovolná omezení specifikovali, zveřejnili je a dodržovali je.

To, že výše uvedený kód je možná přeložený dobře podle standardu, ale ten překlad je naprosto nepoužitelný ve vícevláknových programech, snad vidíte sám.

[little.owl]

Takže standard C jako takový je nepoužitelný pro drtivou většinu vícevláknových programů.

Muzete mi citovat, ktera cast standardu zpusobuje v kontextu uvedeneho prikladu jeho nepouzitelnost ve vice vlaknovem postredi? Soucasny standard C nema thread model, novy ho velmi opatrne zavadi - podobne jako C++11.

To, že výše uvedený kód je možná přeložený dobře podle standardu, ale ten překlad je naprosto nepoužitelný ve vícevláknových programech, snad vidíte sám.

Nevidim. Ten vas priklad neprokazuje nic, preklad se to bude lisit v ramci kontextu jak se pracuje s onou strukturou a tohle muze byt jenom jedna z mnoha variant prekladu. Vy jste totiz udelal jedine - alokoval pamet, podle vseho pouze na stacku a tu potom inicializoval. Nic vic. Pokud pouzijete jine typy ve strukture, treba uint32_t nebo poitery a bude to globalni promenna, kod bude uplne jiny. Zalezi na tom, jak je struktura dale pouzita ci menena atd.

Jak probiha treba takovy task switch na nejnizsi urovni asi vite. Pokud struktura (data) jsou sdilena mezi vlakny, nebude asi vytvarena na stacku, bude globalni promenna a pristup k ni bude chranen synchronizacnimi strukturami. Je plna zodpovednost programatora rici: ted modifikuji kriticka data a dokud nezkoncim nelze provest task switch, jinak by mohlo dojit k poskozeni integrity dat. To neni prace C kompilatoru a ani nemuze byt, stejne jako treba zajisteni integrity dat pri interruptech ci synchronizace sdilenych procesorovych cache.

Cely problem, vcetne problemu v kernelu, byl o tom, jak C pracuje s bit-fields ulozenych ve strukturach, jste si vedom toho, ze ted jste presel uplne nekam jinam?

Ja jiz skoro osum let designuji high speed algoritmy, drivery a aplikace na RTOS systemech (TI DSPs, AD Blackfin, ruzne ARMs, MIPS, SH4, picochip a x86), na polich procesoru, i v certifikovanych systemech, v C, C++, OpenCL a asm; takze nejake zkusenosti asi mam, ale problemy ktere vy nadhazujete mi prijdou dosti divne.

[Filip Jirsák]

Představte si nad tou strukturou následující kód:

//vlákno 1
test.a = 0;
test.c = 0;
test.d = 0;

//vlákno 2
test.b = 0;
for (i = 1; i <= 10; i++) {
  test.b++;
}
assert b == 10;

Z pohledu práce s vlákny tam není žádný problém, nejsou tam žádná data, ke kterým by přistupovala obě vlákna. Takže synchronizace je zbytečná. Ovšem kompilátor, který nebere v úvahu vícevláknový přístup (nebo přerovnání instrukcí procesorem, více vláken ani není potřeba), vygeneruje strojový kód, který nebude vždy fungovat správně.

Ošetřit to obecně nezávisle na implementaci kompilátoru nejde, a i ošetření tohoto konkrétního příkladu se znalostí, jak to kompilátor přeloží, ten kód dost zneefektivní, protože se bude muset přidat zbytečná synchronizace. Jediné rozumné řešení je záruka, že kompilátor takovýhle strojový kód nevytvoří.

pristup k ni bude chranen synchronizacnimi strukturami

To je právě ten problém. Že synchronizace je potřeba vždy, i když se k datům v programu nikdy nepřistupuje z více vláken. Jenže kompilátor C si tam ten přístup z více vláken může potichu vyrobit, když s vlákny nijak nepočítá.

Cely problem, vcetne problemu v kernelu, byl o tom, jak C pracuje s bit-fields ulozenych ve strukturach, jste si vedom toho, ze ted jste presel uplne nekam jinam?

Ne, celý problém je hlouběji. Pokud překladač C s vlákny vůbec nepočítá, může z kódu, který je vícevláknově bezpečný, kdykoli vytvořit strojový kód, který vícevláknově bezpečný není. Prostě někam přidá třeba operaci čtení-zápis, která v jednom vlákně nemá žádný viditelný důsledek, ale ve vícevláknovém prostředí se může stát, že druhé vlákno přepíše hodnotu zrovna mezi načtením a zápisem prvního vlákna. Aby k tomuhle nedocházelo, musí překladač brát vícevláknový přístup v úvahu – i když třeba jinak vlákny vůbec nepodporuje. To, že překladač bere vlákna v úvahu, se pak musí projevit například tím, že budou přesně zdokumentovány případy, kdy překladač může vygenerovat kód, který pracuje s daty tak, že načte i okolní data a pak je nezměněná zase zapíše zpět. Takže by někde muselo být zdokumentováno, že při zápisu do bitového pole může překladač vygenerovat kód, který načte a zapíše zpět hodnoty i z okolních bitových polí ve stejné struktuře.

[little.owl]

Vy se snazite dokazat, ze standard je spatne a pritom ho neznate a davate dohromady nesouvisejici veci. Budu se drzet verze ISO C99+TC3 a mohl bych citovat i konkretni sekce, ale ted se to pokusim vysvetlit po lopate.

Ve vasem prikladu je velmi dulezite, jak byla struktura deklarovana a na jakem systemu vas kod pobezi. Predpokladejme, ze minimalni adresovatelna jednotka je 16 bitu, tedy dva byte, ze se jedna o thready bezici na jednom jadre operujici nad stejnou L1 cache.

Pokud se jedna standardne deklarovanou strukturu, kompilator doplni padding bytes tak, abyste mohl k jednotlivym clenum pristupovat nezavisle systemem pointer+offset a v takovem pripade vas program bude thread-safe. Nicmene, pokud vase struktura bude deklarovana jako packed, padding bytes nejsou doplneny a vy musite pracovat s celou strukturou jako jednou sdilenou promennou nebot system neni diky HW limitacim schopen cist cleny struktury atomicky, a tedy veskere operace s ni musi byt chraneny synchronizacni strukturou a vas priklad nebude nutne fungovat korektne.

Osobne bych nepouzival sdilenou strukturu bez synchronizace ani v prvnim pripade, pokud jsou zapnuty optimalizace a to u vsech mainstreamovych kompilatoru - nejen gcc, ale i od intelu ci microsoftu - zejmena pokud vas kod neni 100% kompatibilni se standardem C. Kompilatory jdou pri optimalizaci tvrde na doraz a za jakoukoliv odchylku od standardu se krvave plati.

Pokud vase struktura bude alokovana na stacku - tedy nebude moci byt sdilena mezi thready, kompilator muze zoptimalizovat kod tak, ze je primo nacitana do 32 bitoveho registru; ostatne mapovani struktura<->registr se pouziva treba u SSE instrukci.

Pokud překladač C s vlákny vůbec nepočítá, může z kódu, který je vícevláknově bezpečný, kdykoli vytvořit strojový kód, který vícevláknově bezpečný není.

Ne, ne, ne. Ja si myslite, ze probiha thread switch?

Takže by někde muselo být zdokumentováno, že při zápisu do bitového pole může překladač vygenerovat kód, který načte a zapíše zpět hodnoty i z okolních bitových polí ve stejné struktuře.

Ale vzdyt do ve standardu je!! Znovu, po X-te, s ohledem na zpusob ulozeni bit-fields ve strukturach nemusi byt pristup k clenum struktury atomicky a programator se podle toho musi zaridit. Muze pouzit workaround s volatile, muze data mit v kriticke sekci.

[Filip Jirsák]

Ve standardu je, že z hlediska vláken nic není zaručeno. S tím se ale nedá pracovat, takže se spolehnete na to, jak to implementuje ten který kompilátor. To je to, co jste popsal na začátku vašeho komentáře – máte nějakou implementaci kompilátoru a spoléháte na to, že bude generovat určitý kód. Stejně, jako na to spoléhali vývojáři jádra. Pak se programátoři kompilátoru rozhodnou, že udělají nějakou optimalizaci, předpoklad, na který jste spoléhal, přestane platit, a program bude občas dělat podivné věci. Lidé od kompilátoru vám řeknu, že to je ale v pořádku, protože standard to nedefinuje. Takže vy tuto konkrétní věc ve svém programu opravíte, a budete čekat na další chybu, která vznikne tím, že spoléháte na něco, co kompilátor teď dělá, ale dělat to nemusí. Podle mne to není dobrý způsob vývoje programu.

Ve vasem prikladu je velmi dulezite, jak byla struktura deklarovana a na jakem systemu vas kod pobezi.

Předpokládejte, že minimální adresovatelná jednotka je 8 bitů a že se jedná o thready běžící na jednom jádře operující nad stejnou L1 cache. Systém dokáže adresovat každý člen struktury, ale kompilátor místo toho použije 32bitové instrukce, protože tím získá rychlejší kód. Všechno je v pořádku, kompilátor splňuje standard, ale výsledek je celkem na houby.

Osobne bych nepouzival sdilenou strukturu bez synchronizace ani v prvnim pripade

Jenže problém je v tom, že o tom, co je sdílená struktura, rozhoduje až kompilátor, a verzi od verze a optimalizaci od optimalizace se to může lišit.

tedy nebude moci byt sdilena mezi thready, kompilator muze zoptimalizovat kod tak, ze je primo nacitana do 32 bitoveho registru

To by ale standard musel s thready počítat. Pokud s nimi nepočítá, může kompilátor zoptimalizovat kód tak, že je přímo načítá do 32 bitového registru, bez ohledu na to, zda může nebo nemůže být ta struktura sdílena mezi vlákny. A pořád bude vyhovovat standardu.

[kralyk z abclinuxu]

Předpokládejte, že minimální adresovatelná jednotka je 8 bitů a že se jedná o thready běžící na jednom jádře operující nad stejnou L1 cache. Systém dokáže adresovat každý člen struktury, ale kompilátor místo toho použije 32bitové instrukce, protože tím získá rychlejší kód. Všechno je v pořádku, kompilátor splňuje standard, ale výsledek je celkem na houby.

Afaik tohle standard nedovouje, ne pokud není struktura packed (což v tomto případně předpokládám by-default není).

Imho pokud by kompilátor přistupoval ke členům té struktury po 32 bitech, zvolil by zarovnání na tuto velikost.

[Filip Jirsák]

Dá se to v tom standardu někde najít? Já se tu na to ptám už dva dny, a citace standardu zatím žádná, u příkladu kódu jsem se pak dozvěděl, že to standard neřeší.

[little.owl]

Nejdulezitejsi cast je zde:

"Each non-bit-field member of a structure or union object is aligned in an implementation- defined manner appropriate to its type."

"Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning."

Pojem "appropriate alignment" vam garantuje schopnost cist data atomicky, pokud strukturu zapakujete (zadny alignment), mate smulu.

Pozor, "non-bit-field member", tam plati jina pravidla, jak jiz vime.

[Filip Jirsák]

To ale popisuje jen způsob uložení dat, ne to, jak se ta data čtou a zapisují. Vy navíc neustále řešíte nejmenší jednotku, se kterou může kompilátor pracovat, ale podstatná je naopak ta největší.

[kralyk z abclinuxu]

To ale popisuje jen způsob uložení dat, ne to, jak se ta data čtou a zapisují.

Jenže to spolu úzce souvisí - alignment. Přečti si komentář ještě jednou.

[Filip Jirsák]

Úzce to souvisí, ale není to to samé. Způsob uložení dat a omezení hardwaru vylučují některé způsoby čtení a zápisu, ale pořád těch způsobů ještě zbývá dost takových, které způsobí dost nepříjemností.

[kralyk z abclinuxu]

No a?

[pc2005]

By mě zajímalo, jak s tím třeba souvisí taky fakt, že paměťová sběrnice je natvrdo třeba 64bit (i u 32bit CPU).

[pc2005]

Doufám ale, že tam jsou aspoň signály typu byte0-x enable (u 72pin SIMM nic takovýho ale nevidím :-O).

[little.owl]

To jen pouze rika jak se plni nejnizsi cache a co se deje kdyz nemate cache hit.

[pc2005]

Víš, kdybych byl troll, tak bych řekl, že ten komp (s 72p SIMM) nemá žadný cache. Takhle jen řeknu, že má jen L1 writetrough .

[little.owl]

Předpokládejte, že minimální adresovatelná jednotka je 8 bitů a že se jedná o thready běžící na jednom jádře operující nad stejnou L1 cache. Systém dokáže adresovat každý člen struktury, ale kompilátor místo toho použije 32bitové instrukce, protože tím získá rychlejší kód. Všechno je v pořádku, kompilátor splňuje standard, ale výsledek je celkem na houby.

Blbost. Mate prostredek, jak tomu zabranit:

struct test { uint8 a; uint8_t b;};
volatile struct test t;

Pokud to nepomuze, kompilator nesplnuje podminky standardu.

To by ale standard musel s thready počítat. Pokud s nimi nepočítá, může kompilátor zoptimalizovat kód tak, že je přímo načítá do 32 bitového registru, bez ohledu na to, zda může nebo nemůže být ta struktura sdílena mezi vlákny. A pořád bude vyhovovat standardu.

Psal jsem o promenne alokovane na stacku, presneji o objektech s "automatic storage duration".

[Filip Jirsák]

Takže ve vícevláknovém programu v C má být každá proměnná označena jako volatile, jinak je program závislý na konkrétní (a často nedokumentované a negarantované) implementaci překladače? Jak budou asi vypadat přeložené programy, kde to tak programátor skutečně použije?

[little.owl]

Ne, tim jen zajistite, ze kompilator neprovede optimalizaci, kdy mapuje strukturu do registru. Volatile zde znamena "neprovadet cachovani".

Volatile je u vicevlaknovych aplikaci temer k nicemu a pokud to bezi na multiprocesorovem systemu se tremi vrstvami cache uplne nicemu a sdileni dat se musi resit prostredky mimo C a jeste velmi opatrne protoze flushovani cache je strasne drahe z hlediska vykonu.

[pc2005]

Volatile je u vicevlaknovych aplikaci temer k nicemu

MMIO?

[little.owl]

To se nevztahuje k synchronizaci vlaken, ale k pristupu k portum a registrum a je to nejuzitecnejsi vyuziti volatile.

Pouzit volatile pro sdilena data je vesmes k nicemu.

[pc2005]

Nefunguje writeback cache tak, že transparentně dělá, že zapsala a přitom kecá?

[little.owl]

Ano, presne tak. Musite tam explicitne vlozit memory fence aby to probublalo nekam pres vrstvy cache dolu. Volatile to nedela, tudiz ty napady o synchronizaci vice vlaken s pouzitim volatile jsou uplne mimo.

Existoval pozadavek aby to volatile delalo, ale bylo to standardizacni komisi C/C++ - nastesti - odmitnuto, viz zde.

[Martin Mareš]

Ano, presne tak. Musite tam explicitne vlozit memory fence aby to probublalo nekam pres vrstvy cache dolu. Volatile to nedela, tudiz ty napady o synchronizaci vice vlaken s pouzitim volatile jsou uplne mimo.

Já nikde netvrdil, že k tomu volatile stačí, nýbrž že pokud přijmete předpoklad, že překladač má právo přistupovat do nesouvisejících proměnných, tak bez volatile to zaručeně správně není.

A nebylo by to správně ani v případě, kdybyste pečlivě volal externí funkci, která se postará o všechny cache a další nekoherentní části paměťové hierarchie.

[little.owl]

překladač má právo přistupovat do nesouvisejících proměnných

To ze jiny clen struktury muzete oznacit jako "nesouvisejici promenou" je dusledkem bodu specifikace popisujici layout struktury v pameti, ktery vsak pro bit-fields explicitne neplati. Uvedomte si, ze mluvite stale o clenu strukturu, nikoliv o nezavisle promenne, nezavisle entite. Pokud ji chcete pouzivat jako "nesouvisejici promenou" na vsech ISO C kompilatorech, nedavejte ji do struktury s bit-fields ci packovane struktury.

[Martin Mareš]

ktery vsak pro bit-fields explicitne neplati.

Kde je to řečeno? Existuje nějaké místo ve standardu, kde by se mluvilo o tom, že struktury obsahující bit-fields se chovají jinak? To, které jste citoval minule, hovoří pouze o bit-field members a non-bit-field members a je aplikovatelné na všechny struktury, ať už v nich položky jednoho nebo druhého druhu jsou či nejsou.

[little.owl]

Vyborne, jsme blizko.

hovoří pouze o bit-field members a non-bit-field members a je aplikovatelné na všechny struktury,

Ano, ano, ano!

Pokud struktura obsahuje pouze non-bit-field members, mate garantovano jak vypada jeji memory layout.

Pokud struktura obsahuje i treba jeden bit-field member, nevite jak je tam kompilator ulozil.

[Martin Mareš]

Memory layout struktury nemám garantovaný nikdy. Padding je implementation-specific, ať už tam bit-fieldy jsou nebo ne. Jinými slovy to, že jestli překladač může při přístupu k položce sáhnout na jinou položku, nezávisí na přítomnosti bit-fieldů.

[little.owl]

U non-bit-field members mate garantovany "implementation-defined alignment appropriate to its type" a mate garantovane poradi ve strukture. To staci; nebot "implementation-defined alignment appropriate to its type" je konzistentni pro dany typ a zarucuje vam, ze treba member uint8_t se chova jako jina promenna uint8_t a muzete psat:

 
struct test {
 uint8_t a;
 uint8_t b;
};

struct test t;
uint8_t aa = 0u;

t.a = aa;
t.b = aa;

Otazka: Proc si myslite, ze bit-fields byly vyslovne vyjmuty?

[Martin Mareš]

Otazka: Proc si myslite, ze bit-fields byly vyslovne vyjmuty?

Aby jejich kodovani mohlo byt implementation-defined, nikoliv aby mohly ovlivňovat chování non-bit-fields.

[little.owl]

To se mi moc nezda. Mam pocit, ze davate dohromady dve veci: (1) kodovani v "addressable storage unit" (2) ulozeni "addressable storage unit" ve strukture.

Jenze struktura je jen container a neni dulezite jaka je vnitrni binarni reprezentace jejich memberu, jak jsou jejich bity poskladany a jaky maji vyznam.

[Martin Mareš]

Já si to, co říká standard, vykládám takto: Každá proměnná, která není bit-field, je uložena v jedné nebo několika addressable storage units (říkejme bytech, ať už to má kolik chce bitů), ve kterých kromě ní může být jenom padding. Bit-fieldy, které se ve struktuře nacházejí za sebou, jsou implementačně definovaným způsobem zakódovány do bytů, ve kterých jsou pouze tyto bit-fieldy a případně padding. Struktura se pak skládá z bytů svých prvků a a potenciálně dalšího paddingu.

Co mi přijde sporné, je, nakolik překladač smí sahat na byty, ve kterých nejsou uloženy proměnné, s nimiž se pracuje. Právo mu k tomu dává v zásadě jenom obecný princip "překladač může dělat cokoliv, o čem lze dokázat, že to nezmění chovaní programu". To je ale velice široké pravidlo, které povoluje i věci, které jsou proti zdravému rozumu a všichni spoléhají na to, že se nestanou. A alespoň na systémech s POSIXovými vlákny je zřejmě pravidlo "mimo používané proměnné se nesahá" všemi implicitně předpokládáno, protože bez něj by v podstatě žádný vícevláknový program nemohl být korektní.

[little.owl]

Ja to po precteni standardu chapu jinak.

A) Mate "normalni" strukturu ktera obsahuje "normalni" typy jako int, char a podobne. Syntaxe:

struct test {
  int  a;
  char b;
};

Je to container, obsahuje data s definovanou strukturou a alignmentem, poradi clenu je takove jak bylo deklarovano, cleny musi mit jmeno a muze se k nim pristupovat metodou pointer + offset, funguje operator offsetof(). V jazyku C od sameho pocatku.

B) Pak jsou tu bit-fields. Syntaxe:

struct test {
  unsigned:2;
  unsigned:0;
  unsigned:1;  
}

Je to pytel bitu, vsechno je implementacne zavisle, cleny nepotrebuji jmeno, pristupovat k bitum metodou poiter + offset nelze nebot nemaji adresu a operator offsetof() nefunguje. Do jazyka pridany o neco pozdeji.

To znamena, ze struktury (A) a bif-fields (B) jsou v podstate uplne jine typy pouze deklarovane se stejnou syntaxi. Pak standard, jak je napsan, zacne davat smysl.

[pc2005]

Já jen, že pokud volatile ten zápis skutečně neoptimalizuje, tak pokud data v cache budou (celkem pravděpodobné), hodnota se normálně do cache zapíše a pokud jí někdo vyžádá, tak se zase vezme. Jedinej problém by byl u DMA, ale to je většinou blok paměti.

[little.owl]

Votile nedela nic jineho, nez ze donuti provest load/store operace presne jak je to napsano a vynuti si presne provadeni operaci podle sequence points. V podstate zabije jakoukoliv optimalizaci, mate mizerny pomaly kod a jeste to ve vicevlaknovych aplikacich nefunguje. Krom mapovani portu/registru je to k nicemu. Navic si s tim kazdy kompilator dela ve spornych situacich co chce, takze nakonec musite koukat do asm listingu, abyste si byl jist co to dela. Je to mor.

[pc2005]

No já reagoval na tohle (měl jsem napsat explicitně).

Volatile zde znamena "neprovadet cachovani".

[Martin Mareš]

Opět, writeback je alespoň na amd64/i386 zcela koherentní.

Jediné případy, kdy zápis do paměti není okamžitě viditelný na ostatních procesorech, jsou (1) situace, kdy se zápis ještě nedostal ani do cache, protože instrukce ještě nebyla zcela dokončena, (2) streaming memory access pomocí SSE.

[little.owl]

Stale mluvite jen procesor pro PC, ale svet je pestrejsi.

[Martin Mareš]

Vy víte o jakémkoliv moderním multiprocesorovém systému, který by neměl koherentní cache? Neznám do detailu všelijaké obludky o tisících procesorů, ale ty, ke kterým jsem trochu přičichl, také byly koherentní.

Ostatně na nekoherentní architektuře by každé synchronizační primitivum muselo vysypat celý obsah cache, což je neúnosné (i ve srovnání s tím, jak brzdí zajišťování koherence).

[little.owl]

Mam tu ted pred sebou system kde dva modifikovane jadra Cortex M3 like sdileji L2 cache a pres L3 jsou spojeny s jadrem Cortex A8. Fakt, ze data jsou viditelna na urovni L2 nezarucuje, ze A8 to take vidi. Musi se to hlidat manualne. AD a TI DSPs, muzou menit cache strategii, nebo cast zni zmenit na rychlou pamet, a to za chodu procesoru - i kdyz je to cerna magie. Picochip, to je kapitola sama pro sebe ci procesorova pole Renesas. Krasa C99 je v tom, ze kdyz to napisete dobre, chodi to temer vsude; mensi cast platform zavisle kodu se musi ovsem izolovat.

Ostatně na nekoherentní architektuře by každé synchronizační primitivum muselo vysypat celý obsah cache, což je neúnosné.

Staci jen prislusne radky a pouziti synchronizacnich primitiv muze programator kontrolvat.

[Martin Mareš]

Mam tu ted pred sebou system kde dva modifikovane jadra Cortex M3 like sdileji L2 cache a pres L3 jsou spojeny s jadrem Cortex A8.

Ve světě embedded systémů je samozřejmě možné cokoliv

Staci jen prislusne radky a pouziti synchronizacnich primitiv muze programator kontrolvat.

Problém je, že klasické synchronizační primitivum nic neví o tom, které řádky cache patří do kritické sekce a které nikoliv. Takže mu nezbude než vysypat všechno.

[little.owl]

Ve světě embedded systémů je samozřejmě možné cokoliv

Ten SoC ma jeste DSP a Cortex A9, image processor, hw JPEG decoder, EMAC a vse to sdili jednu DDR. Z toho by se jeden po**al.

Problém je, že klasické synchronizační primitivum nic neví o tom, které řádky cache patří do kritické sekce a které nikoliv.

Mohu flushovat i konkretni radky cache, a nebo i konkretni objekty v pameti (position, size); dobry sluha, zly pan.

[Martin Mareš]

Mohu flushovat i konkretni radky cache, a nebo i konkretni objekty v pameti (position, size); dobry sluha, zly pan.

To jasně, ale už to pak nemohu ovládat klasickými POSIXovými synchronizačními primitivy.

[pc2005]

No ono třeba to TI DSP se skoro klasickým C kompilátorem ani používat nedá. Škoda, že linux c6x ještě nebyl mainline (v době kdy jsem měl příslušný hw), ta optimalizace bude dost ubohá imho.

[little.owl]

Ja pisi hodne algoritmu pro radu TMS320C6xxx a jde to v pohode. Musite psat v Embedded C++, hrat si s kompilatorem a iterovat uprava codu <-> asm listing az to vypada dobre. Jen u kritickych casti se pise neco v asm - prilis pracne, protoze tech vypocetnich jednotek a jader je tam docela dost; navic vetsina zakazniku to ani nechce.

PS: Na Integru se vykaslete, pokud nechcete utrpet dusevni ujmu.

[pc2005]

Jo to jsem myslel, že je nutný použít kompiler co nejvíc ušitý na míru c6x, ale konvergování k optimu pomocí ručních multipass je dost slabota . Ale neříkám, že to nejde.

Jo? S Integrou jsou problémy? Já nemám žádnou desku, protože vrážet takový prachy do tý referenční od TI se mě nechce. V patičce to bylo v době, kdy nejlevnější a nejrychlejší ARM na trhu byl beagleboard s OMAP3. Teďka se stopro stav změnil (abych pravdu řekl, už před časem jsem začal přemýšlet na co patičku změnit ). Ta Integra byla dobrá, jelikož má MAC, PCIe a ~1GHz.

Až se bude prodávat něco s Cortex-A15 MPCore to bude jiný kafe .

[little.owl]

kompiler co nejvíc ušitý na míru

Takovy existuje a dodava ho TI.

ručních multipass

Dela se to naprosto bezne, s trochou zkusenosti mate dobre vysledky; vyvoj jen v assembleru by nikdo nezaplatil a hlavne na to nejsou lidi.

S Integrou jsou problémy?

S celou radou. Pracoval jsem na odvozenych procesorech driv nez byly uvedeny oficialne na trh. TI ma zvyk nechavat sve prvni zakazniky testovat jejich "produkcni" [alpha] knihovny, kdy nic stabilne nefunguje. Zkoncite mezi svym zakaznikem chtejicim funkcni vyrobek a TI, tvrdicim, ze problem resi a nic se mesice nedeje a zaroven neni dokumentace - jen binarky - kvuli know-how. Lepsi kupovat veci stare dva tri roky kdy to uz jini jejich zakaznici odladili.

takový prachy do tý referenční od TI se mě nechce

Zivotnost referencni desky pri vyvoji je tak 3-5 mesicu a pouziva se to nez mate svuj HW prototyp. Pro amatera vyhozeny prachy, zakladni EVM a JTAG a minimalni vyvojovy SW muze stat pres 2500 euro.

Ta Integra byla dobrá, jelikož má MAC, PCIe a ~1GHz.

To ma, ale proc to potrebujete? Pokud si chcete hrat kupte si Beagleboard ci Pandaboard a usetrene penize radsi prochlastejte.

[pc2005]

Jo vím, že ho dodává, současně s knihovnama předem napsaných funkcí. Jinak optimální by právě bylo, kdyby ty jednotlivý průchody dělal přímo kompiler.

Pokud jsou problémy s knihovnama tak OK, horší by bylo pokud by byly fatální problémy s hw. Tohle testování ale dělaj všichni. Koneckonců i kernel je založen na neustalém posílání patchů .

ad deska: Jo proto se ptám zda není nějaká levnější typu beagle(panda)board (v době psaní ještě nebyla verze s ethernetem). Měl jsem totiž takovou chuť (a pořád ještě mám) se na x86 totálně vykašlat a přejít na ARM. Problém byl v tom, že podmínky byly rozšiřitelnost (ve smyslu a rychlosti PCI(e) karet) přes cokoliv kromě usb, ethernet (taky radši ne přes usb - blé latence) a SATA (to usb nestíhá) a rychlost a paměťové nároky vtší než duron 600MHz. V tý době jsem našel jen Integru a po čase něco od Samsungu. Mezitím jsem ale výhodně koupil miniITX x86 desku, takže ta potřeba ARMu se zmenšila (ale taky mě stála ta x86 nemalý počet šedivých vlasů - f*ck socket P a M).

[little.owl]

horší by bylo pokud by byly fatální problémy s hw.

Z vaseho hlediska je to jedno jestli je to HW nebo SW, vy mate binarni blob a nechodi to. Za binarnim blobem jsou schovany dalsi procesory a periferie a vy o nich nic oficialne nevite. BTW, integrace Ducati subsystem teto rady je pomerne zabugovana a je to chyba HW.

mě stála ta x86 nemalý počet šedivých vlasů

Tak s Integrou by to bylo mnohem horsi.

[pc2005]

Tak s Integrou by to bylo mnohem horsi.

Bude mít ale lepší dokumentaci a ani nebude mít problém s paticí .

[Voty]

Že zasahuji do debaty, ale zkusím se zeptat takto. Mějme následující kód.

static unsigned char a; static unsigned char b;

vlakno_a() { while(true) { unsgigned tmp = a; a++; tmp++; assert(a == tmp); } }

vlakno_b() { while(true) { unsgigned tmp = b; b++; tmp++; assert(b == tmp); } }

Tedy, není nic ve strukturách, nejsou zapnuté různé packed věci atp, zaručuje mi standard C (C++), že toto bude fungovat (nevypadne na assert)?. Jinými slovy, může překladač v takovémto případě provést optimalizaci, že při modifikaci objektu a provede i modifikaci objektu b?

Dále bych měl otázku na proměnné na stacku, zda-li se tyto nějak liší, od statických, neboť ty přece můžu také sdílet mezi vlákny (myslím tím např. stack funkce, která tyto dvě vlákna spustí).

[Voty]

V těch vláknech má být pochopitelně. unsigned char tmp =

[little.owl]

Kompilator vam muze funkce zoptimalizovat tak, ze vam z kodu nic nezbude; pokud nepouzijete klicove slovo volatile a nakonec muze jen volat assert(true);

Jinými slovy, může překladač v takovémto případě provést optimalizaci, že při modifikaci objektu a provede i modifikaci objektu b?

Ne, nemuze vkladat zavislosti.

Dále bych měl otázku na proměnné na stacku, zda-li se tyto nějak liší, od statických.

Promenna na stacku nemuze byt sdilena mezi vlakny, je alokovana behem behu programu, staticka/globalni promenna je alokovana pri kompilaci.

[little.owl]

OK, technicky byt muze byt promenna na stacku sdilena mezi vlakny, ale musite zajistit ze bude existovat, kdyz je potreba.

Treba:

// thread fnc
int fnc(){
 volatile int a; // predat pointer dalsimu vlaknu
 for (;;) {
   ...
 }
}

[Martin Mareš]

Že se takové věci stanou na stroji s minimální adresovatelnou jednotkou větší než 1 byte, to je samozřejmě jasné. Jenže v případě, o kterém je řeč, se to přihodilo proměnné, která je evidentně větší než minimální adresovatelná jednotka.

[little.owl]

Ne.

Prihodilo se ve strukture obsahujici bit-fields a tam standard stanovi explicitne jina pravidla.

[Martin Mareš]

Standard stanovuje zvláštní pravidla pro reprezentaci bit-fieldů. Kde je v něm psáno cokoliv o tom, že reprezentace ostatních členů struktury může záviset na přítomnosti bit-fieldů? V sekci 6.7.2.1 nic takového nevidím.

[little.owl]

To dusledek 6.7.2.1. Standard vyzaduje korektni alignment pouze u non-bit-field members, nikoliv u struktur ktere je obsahuji a to umyslne, a dokonce u bit-fields nemate ani garantovane poradi ve strukture - muzete je pouzit jako padding bytes - da se tak usetrit hodne pameti, ale dochazi k jevu, ktery se zde stal - nacitate je spolecne s jinym membery.

... ostatních členů struktury může záviset ...

Takhle standardy nefunguji. Ma psano co musite, zbytek neni vyzadovan a nelze na nej spolehat.

[Martin Mareš]

Takhle standardy nefunguji. Ma psano co musite, zbytek neni vyzadovan a nelze na nej spolehat.

Jasně, že pokud vás zajímá jen to, zda překladač vyhovuje standardu, tak se na to nelze spolehnout. Jenže jak už jsem psal, pokud se spoléháte pouze na standard, nelze v C99 napsat korektní vícevláknový program, leda že by vše bylo volatile. Takže v praxi se spoléhá na "rozumné chování" překladače, tedy že překladač nebude dělat věci, které jsou sice formálně korektní, ale nedávají smysl. Překladač by úplně stejně jako na sousední položku struktury mohl sáhnout na nějakou naprosto nesouvisející proměnnou. Všichni víme, že to neudělá, a v životě na to takřka denně spoléháme. S C99 nelze lépe.

[little.owl]

Volatile vam vubec nepomuze a compiler take ne, protoze za vas nemuze efektivne udelat cache management, lockovani ci uzivat memory barriers.

A nebo chcete z C udelat high level language?

Překladač by úplně stejně jako na sousední položku struktury mohl sáhnout na nějakou naprosto nesouvisející proměnnou.

To by byl samozrejme bug.

C99 je fajn. Chece psat v portovatelny kod behajici na mnoha platformach, nebo jen v GCC?

[Martin Mareš]

compiler take ne, protoze za vas nemuze efektivne udelat cache management, lockovani ci uzivat memory barriers.

To je pravda, ale aspoň mi nemusí házet klacky pod nohy, když si na cache management a spol. budu volat externí knihovnu.

Chece psat v portovatelny kod behajici na mnoha platformach, nebo jen v GCC?

Zde je řeč o kernelu, takže GCC.

Jinak se samozřejmě snažím psát portabilně, přesněji řečeno pro rozumné implementace C99 (korektní implementace klidně může omezit velikost zásobníku na 4KB a přesnost floatů 6 cifer, s čímž se nedá programovat, ale rozumná implementace to nikdy neudělá, takže mi to je jedno).

[little.owl]

Standard rika to byt implementovano nemusi, nicmene muze a od gcc bych ocekaval konzistentni chovani na vsech platformach, pokud tam neni nejaky zavazny duvod. Tedy pozadavek konzistence asi staci na oznaceni chovani bez volatile jako bug, i kdyz je to formalne v poradku.

Nicmene pohadky o znemozneni vicevlaknoveho programovani neberu.

[Martin Mareš]

Nicmene pohadky o znemozneni vicevlaknoveho programovani neberu.

Pokud byste se řídil čistě podle kombinace C99 a POSIX threads, tak korektní vícevláknový program prostě nenapíšete. Leda že byste úplně každou proměnnou označil jako volatile.

[little.owl]

Leda že byste úplně každou proměnnou označil jako volatile

Myslite kazdou sdilenou promennou? To jich sdilite tolik? K cemu vlastne volatile zde chcete pouzit?

C99 a POSIX threads

ISO C a POSIX, rozdil je predevsim ve standardni knihovne jazyka - signals, system calls, raise() ktery muze poslat signal jinemu threadu, threads, pids, lepsi localizace, implementace knihovny muze byt vice "system specific". Ale standard vlastniho jazyka je vsak stejny (ISO C), tak jak vam to tedy zde pomuze?

[Filip Jirsák]

Myslite kazdou sdilenou promennou? To jich sdilite tolik?

Celou dobu se tady řeší problém, že kompilátor udělá sdílenou proměnnou z něčeho, co původně sdílené proměnná nebyla.

[little.owl]

Budu nezmar.

Neudela.

On vam vygeneruje kod, kde pristup k promene s ohledem na task switch nebo interrupt muze mit side effect. To je ale celkem bezne pokud zapnete optimalizace - prelozte neco s gcc -02 a kouknete se na vygenerovany kod. Pokud byste chtel neco jineho, zabil byste nejdulezitejsi metody optimalizace na rychlost, vcetne veci jako je instruction reordering.

Pritom, polopaticky, je to velmi jednoduche: prvky zapakovane struktury nebo struktury obsahujici bit-fields nemohou byt nikdy povazovany za samostatne entity a cela struktura pak musi byt vzdy chapana jako jedna promenna.

[Martin Mareš]

On vam vygeneruje kod, kde pristup k promene s ohledem na task switch nebo interrupt muze mit side effect. To je ale celkem bezne pokud zapnete optimalizace - prelozte neco s gcc -02 a kouknete se na vygenerovany kod. Pokud byste chtel neco jineho, zabil byste nejdulezitejsi metody optimalizace na rychlost, vcetne veci jako je instruction reordering.

Ne, žádná z těchto optimalizací nezpůsobí, že by program přistoupil k proměnné, která není ve zdrojáku vůbec použita.

Instruction reordering se neprovádí přes hranice volání externích funkcí, o nichž překladač nic neví (takže je bezpečné volat synchronizační primitivum z knihovny).

Pritom, polopaticky, je to velmi jednoduche: prvky zapakovane struktury nebo struktury obsahujici bit-fields nemohou byt nikdy povazovany za samostatne entity a cela struktura pak musi byt vzdy chapana jako jedna promenna.

Nesouhlasím. Nic takového se ve standardu nepíše (a když jsem se ptal, nebyl jste schopen žádné takové pravidlo odcitovat, pouze jste zmiňoval implementací definovaný alignment, ale ten se týká i struktur, které žádný bit-field neobsahují).

[little.owl]

nezpůsobí, že by program přistoupil k proměnné, která není ve zdrojáku vůbec použita.

Chtel jsem ilustrovat, ze zpusobuji side effects, ktere narusi integritu v case a cini problemy pri task switch.

Nic takového se ve standardu nepíše

A jsme zpet. Standard negarantuje s ohledem na temer nulove pozadavky na umisteni bit-fields ve strukturach, ze budete moci cist prvky bez side effect.

zmiňoval implementací definovaný alignment, ale ten se týká i struktur, které žádný bit-field neobsahují

Dulezite je, ze se explicitne netyka bit-fields. Jsou vyjmuty z pozadavku. V-Y-J-M-U-T-Y => nemate zadne garance na korektni alignment.

[Martin Mareš]

Standard negarantuje s ohledem na temer nulove pozadavky na umisteni bit-fields ve strukturach, ze budete moci cist prvky bez side effect.

Standard neříká nic o tom, že by chování non-bit-fieldů mohlo být jakkoliv ovlivněno chováním bit-fieldů.

Dulezite je, ze se explicitne netyka bit-fields. Jsou vyjmuty z pozadavku. V-Y-J-M-U-T-Y => nemate zadne garance na korektni alignment.

O alignmentu bit-fieldů také od začátku netvrdím vůbec nic. Jediné, co říkám, je, že přítomnost bit-fieldů nemá způsobit side-efekt na ostatních položkách.

[pc2005]

Hmmm možná byste se lépe domluvili, kdybyste operovali nad reálným kusem vícevláknového kódu.

[little.owl]

Priklad je k nicemu. Soucasne C vlakna vubec nezna, stejne jako synchronizacni struktury. To je zalezitost operacniho systemu nebo specializovane knihovny poskytnout prislusne prostredky a tam je to nakonec stejne psano ne nejnizsi urovni v assembleru prislusneho procesoru (nejaky CAS) nebo se pouzivaji specialni periferie - takze zadne C.

[kralyk z abclinuxu]

Rejp naokraj: C11 threading a snychronizaci obsahuje.

Nicméně je pravda, že v diskusi o linux kernelu to asi nemá moc relevanci, vzhledem k tomu, že jádro moc nepoužívá ani C99.

[little.owl]

On i pripravovany novy standard C ho take obsahuje a je to podobne.

[kralyk z abclinuxu]

No to bude on, ten C11, alias C1X, alias ISO standard číslo nevim kolik přijatý v prosinci... Žádný novější snad od tý doby není

[little.owl]

On uz je prijaty?

Mate final draft? Mluvime o C11, nikoliv o C++11?

[kralyk z abclinuxu]

Jo, byla tu o tom zprávička. Případně wiki.

[little.owl]

Mam verzi N1570 April 12, 2011, je nekde neco novejsiho?

[kralyk z abclinuxu]

Afaik ne.

[little.owl]

Diky, v prosinci a lednu jsem honil projekt, nemel jsem cas vubec nic sledovat. Zamestnavatel koupi standard, ale v jen papirove podobe :-/.

[Filip Jirsák]

To, že C vlákna vůbec nezná, ovšem neznamená, že v něm lze bez problémů programovat vícevláknově, jenom si to musí programátor sám ošetřit. Pokud některé věci nezaruší kompilátor, musel by programátor ošetřovat každý řádek kódu zvlášť - a program by se neuvěřitelně zpomalil, protože by byl plný zbytečných synchronizací.

Výše uvedený příklad ukazuje, že v C podle standardu vícevláknově prakticky nejde programovat – jedině pokud se spoléháte na to, že kompilátor některé věci neudělá. Pak jste ale samozřejmě závislí na konkrétní implementaci kompilátoru, a navíc ještě na tom, že se to chování kompilátoru nezmění.

[little.owl]

Staci osetrit data sdilena mezi vlakny.

Na urovni OS muzou byt nekdy problemy, ale to se resi tak, ze se z C utece a napise se to ve strojovem kodu.

[Filip Jirsák]

Jenže tady se bavím o případu, kdy ve zdrojáku v C žádné sdílení mezi vlákny není, a přidá ho tam až konkrétní překladač. A protože překladač přece nic neví o vláknech, tak to sdílení mezi vlákny může přidat kamkoli, kam ho napadne.

[Martin Mareš]

Přesně tak.

A v podstatě všechno vícevláknové programování doteď spoléhalo na to, že překladač nedělá věci, které jsou sice podle litery standardu korektní, ale jinak naprosto nesmyslné. Jako například při operování s proměnnou pracovat i s nějakou jinou, úplně nesouvisející proměnnou.

Nebýt tohoto nepsaného předpokladu, jediná možnost, jak napsat korektní vícevláknový kód, by byla napsat k prakticky všem proměnným volatile, čímž by vzniklo něco nepoužitelně pomalého.

Takže nezbývá, než buďto počkat, až bude GCC umět solidní formální memory model, jako třeba ten z C11, nebo GCC odnaučit dělat praštěnosti (a tato konkrétní praštěnost je tak jako tak špatně i formálně, protože připsat volatile nepomůže).

[Filip Jirsák]

Díky, už jsem se začínal bát, že ta sáhodlouhá diskuse bude k ničemu a nedozvím se, jak to tedy je.

Podle článku soudím, že lidé od GCC budou ty „praštěnosti“ spíš hájit, ale doufám, že z toho vyplyne alespoň to, že se tyhle „praštěnosti“ nebo řekněme sporná místa zdokumentují a ze strany GCC bude nějaký závazek, že nebudou bez konzultací a varování přidávat další podobné špeky.

[Martin Mareš]

Lidé od GCC přiznávají, že příslušný kód je špatně (protože v případě s volatile jasně špatně je), ale že ho nedovedou jednoduše opravit. Dlouhodobě z toho doufejme vyplyne, že kód kolem bitfieldů bude kompletně přepsán a GCC přejde na nějaký lépe definovaný model přístupu k paměti (asi ten z C11 + možná nějaké záruky navíc).

[little.owl]

Bitfields bych nechal jak jsou. Ono to rozumne opravit nejde, pokud nezavedete pozadavek bitove adresace.

[Martin Mareš]

Norma hovoří o tom, že bit-fieldy se pakují do nějakých větších objektů. Rozhodně nezmiňuje, že by se dal bit-field spakovat do jednoho objektu s jiným členem struktury. Současná implementace to efektivně dělá a není k tomu žádný rozumný důvod.

[whata]

To není nutné, po tomhle si nejsem vůbec jistý, zda jste původní problém pochopil. Problém je, že gcc při přístupu k bitfield míchá do operace zcela jinou, nesouvisející proměnnou, která ani bitfield není. Takže v principu stačí omezit kompilátor, aby nezasahoval mimo proměnné bitfields (neomezuje-li ho v tom jiný constraint architektury a pak by měl ABI specifikovat jiné rozložení).

Mimochodem, zajímalo by mě, co s tím udělá procesor, resp. jeho cache. Když mám unsigned char c; (global) a v kódu c++, vážně si procesor stáhne a uloží jediný byte, nebo natáhne do cache větší kus a tím prakticky udělá to samé, co v tomto případě kompilátor?

[Martin Mareš]

Natáhne do cache větší kus (celý řádek, dneska typicky 64B), ale cache se mezi procesory chová koherentně, takže tím žádný problém nevznikne.

[little.owl]

Jde o ze verze bez volatile se chova korektne, s volatile nikoliv. Prvni byl bug v kernelu, druhy v gcc.

... aby nezasahoval mimo proměnné bitfields

To lze vynutit pomoci volatile. Proc to tedy zbytecne limitovat a zavadet jako defaultni chovani?

... vážně si procesor stáhne a uloží jediný byte, nebo natáhne do cache větší kus a tím prakticky udělá to samé ...

Ano, udela totez, a je to jeste horsi. Cache se nacita ve vetsich blocich a tak muzete klidne nacitat i 2024 bytu kvuli jednomu byte. Navic, kdyz mate tri cache L1/L2/L3, kazda muze pouzivat jinou velikost radku a nebo byt sdilena s jinym jadrem. Pokud chcete vykon, musite optimalizovat memory layout aplikace a velmi casto i cache management - rikate kdy a ktere radky se maji radky zapsat do pameti. Dalsi krasna vec je DMA nebo dynamicke mapovani cache na rychlou pamet behem behu programu. Je toho plno a proto jsem skeptik, kdyz nekdo veri ze kompilator to vyresi.

[Martin Mareš]

Proc to tedy zbytecne limitovat a zavadet jako defaultni chovani?

Protože je to v podstatě jediný způsob, jak generovat efektivní kód. Učinit z toho defaultní chování možná zabrání nějakým marginálním optimalizacím (zatím nikdo o žádné takové neví), psát ve všech takových případech volatile znemožní optimalizace úplně.

Ano, udela totez, a je to jeste horsi. Cache se nacita ve vetsich blocich a tak muzete klidne nacitat i 2024 bytu kvuli jednomu byte.

Na korektnost to ovšem nemá vliv, jen na rychlost. Cache je koherentní.

[little.owl]

že ho nedovedou jednoduše opravit.

Hardwarova limitace ... proto jsou pozadavky ohledne bitfields specificke a pomerne volne.

[little.owl]

Jako například při operování s proměnnou pracovat i s nějakou jinou, úplně nesouvisející proměnnou.

Dobre, tedy otazka.

Jak chcete zabranit tomu, ze pri modifika aa neni i bb a cc nactena do pameti a zase zapsana zpet na systemu, ktery neumi zpracovavat data v blocich mensich nez byte (8bitu) a nepodporuje bitovou adresaci, bez toho aniz byste tam daval padding bytes?

struct test {
	unsigned aa:1;
	unsigned bb:2;
	unsigned cc:1;
}

[Martin Mareš]

Bitová pole se obvykle nechápou jako samostatné proměnné – norma jasně hovoří o tom, že se pakují nespecifikovaným způsobem do větších proměnných. Proto od nich nikdo nezávislé chování nečeká.

Stejně tak nikdo nečeká, že bude nezávislý přístup k čemukoliv menšímu než nejmenší adresovatelná jednotka na daném stroji.

[little.owl]

Ne. Norma specifikuje, jak se struktury pakuji, sekce 6.7.2.1, bod 10. Je tam nejaky stupen volnosti, aby zbytecne nelimitovali HW.

[Martin Mareš]

Bod 10 se ovšem týká jen bit-fieldů.

[little.owl]

Struktur s bitfieldy. A vyse jsem citoval jak se tvori struktury bez nich.

[Martin Mareš]

Cituji zmíněný bod 10:

An implementation may allocate any addressable storage unit large enough to hold a bit-field. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit. If insufficient space remains, whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is implementation-defined. The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined. The alignment of the addressable storage unit is unspecified.

Kde se zde hovoří o něčem jiném než bit-fieldech?

[little.owl]

Musite cist vsechno, precte si jeste k tomu:

Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared.

Each non-bit-field member of a structure or union object is aligned in an implementation- defined manner appropriate to its type.

Ta vyjimka pro non-bit-field je umysl.

Dusledkem je, ze non-bit-field members muzete pouzit i jako padding bytes, ale nemate garantovane ani jejich spravne poradi. Pokud jsou pouzity jako padding, nemate garantovano, ze pri jejich cteni se nectou i dalsi "normalni" cleny.

[Martin Mareš]

Vaše intepretace standardu mi přijde jako přinejmenším dost kreativní

Nevím o jakékoliv klauzuli standardu, která by připouštěla, aby padding nesl jakýkoliv význam, kromě toho, že některé kombinaci padding bitů u integerů mohou trapovat.

[little.owl]

některé kombinaci padding bitů u integerů mohou trapovat.

To je vec HW.

Treba u ARMu lze vyjimku zakazat, u nektereho third party kodu jsem to musel udelat a sam se divim, ze to vubec chodi a vim jake auto nemam kupovat.

Vaše intepretace standardu mi přijde jako přinejmenším dost kreativní

Komicke je, ze by to bylo formalne asi OK, ale stejne bych to nepouzil. Nemicham bit-fields a normalni data ve strukture, ale v kombinaci s union se daji delat hezke veci a union u clen struktury byt v pohode muze.

[Martin Mareš]

Mimochodem, také se mluví o tom, že ten alignment je implementation-defined, nikoliv undefined, a nevšiml jsem si, že by GCC v seznamu implementation-defined vlastností uvádělo nějaké takhle obskurní pravidlo pro alignment :)

[little.owl]

Ano, implementation-defined; duvody pro alignment jsou HW limitace a souvisejici moznost cist korektne data a rychlost. Nikdo vam nebrani pouzit 4 bytes alignment a pouzit prostredni dva a podobne zhuverilosti.

GCC v seznamu implementation-defined vlastností uvádělo nějaké takhle obskurní pravidlo pro alignment :)

Tusite kde?

[sigma]

On je to vůbec v C bordel.

Druhá strana - když se programuje v C pro 8bit platformu (třeba Atmel AVR), a kompiluje se to GCC. Potom volatile na 16bit a větší proměnné vůbec nezaručuje, že její obsah bude konzistentní. Tj. mezi čtením jednotlivých bajtů může přijít IRQ, v jehož obsluze se hodnota změní. Údajně je volatile jen taková pomůcka pro kompilátor, že nemůže přístup k dané proměnné optimalizovat - třeba vyhodit podmínku, která by v běžném kontextu byla vždy (ne)splněná.

Takže se musí v kritických místech používat ATOMIC makra, která zajistí zákaz přerušení. Zas kdyby to dělal kompilátor okolo každé operace s volatile proměnnou, cena by byla děsivá. Dost divoká je implementace těch ATOMIC konstrukcí - právě proto, že C toho moc nezaručuje, tak se to řeší nějak pomocí for konstrukce.

[little.owl]

Sorry, bordel v tom neni, to jen vy mate restriktivni ocekavani.

Volatile vam negarantuje atomicitu operace a uz vubec ne u asynchronnich udalosti jako je IRQ, co vam zarucuje je napsano ve standardu.

Ano, promenna, jejiz hodnota je ctena/zapisovana v interrupt mode musite byt v aplikaci nejak chranena, to je znamy fakt a pokud tomu tak neni, je to normalni bug. Atomicke operace v podstate nemuzete efektivne implementovat bez podpory v instrukcni sade a C vam nemuze zarucovat vice, aniz by nekladlo dodatecne pozadavky na HW implementaci, coz by nakonec jen omezilo portabilitu codu.

[little.owl]

Abych svuj rant dokoncil - C99 pro to definuje typ sig_atomic_t, coz je

... integer type of an object that can be accessed as an atomic entity, even in the presence of asynchronous interrupts.

Pokud nekdo pouzije jiny typ, i treba s volatile, a pak je prekvapen, ze to v interruptu nefunguje, je u chyba u nej, nikoliv bordel v C.

U AVR to bude neco jako "typedef int8_t sig_atomic_t;" a pak je vse OK.

[kralyk z abclinuxu]

Údajně je volatile jen taková pomůcka pro kompilátor, že nemůže přístup k dané proměnné optimalizovat

Přesně tak, to je originální váznam volatile, že narozdíl od normální proměnné kompilátor nemůže předpokládat, že se hodnota té proměnné "samovolně" nezmění od instrukce k instrukci. Hodnotu ve volatile proměnné může kdykoli změnit externí vliv, jako např. jiný process, thread, hardware atd..., takže volatile proměnná se vždy načte. AFAIK toto a pouze toto zaručuje příznak volatile, nic víc.

Druhotné použití pak je vypnutí optimalizací (i když se hodnota "samovolně" nemění), na x86 se to například dá použít pro zajištění determinističnosti FPU (ale nestačí to bohužel samo o sobě).

[Martin Mareš]

Nikoliv, volatile je daleko silnější. Říká, že každý přístup k proměnné musí být přeložen tak, jak byl zapsán. Čili například a=1; a=2; nelze nahradit jedním přiřazením.

[kralyk z abclinuxu]

Aha, ok...

[Sten]

To první mi přijde jakžtakž odůvodnitelné. Struktura říká, že se nebude měnit — OK, pracujte s ní, jak je libo, hlavně ať je to rychlé.

Nicméně že to nefunguje ani u volatile, to už je fakt problém.

[frr]

Když na to koukám líp a déle:

• GCC v této operaci nepředpokládá, že by program mohl běžet paralelně ve více vláknech na více jádrech. Proto si troufne provést operaci na dvou proměnných zároveň, která je atomická jenom v případě běhu na jediném CPU jádře.
• Proto pokud chcete concurrent access z více vláken (na více CPU jádrech) do sdíleného structu, máte použít explicitní zamykání - a to i v případě že víte, že kód programu zajišťuje, že nebude docházet ke zjevným (ve zdrojáku viditelným) problémům typu "race condition při read-modify-write".
• Problém se myslím netýká pouze kernelu, stejně by to IMO dopadlo v user-space programu s použitím libpthread, kde více vláken sahá bez zamykání do sdíleného structu.
• Osobně takovéhle "bezzámkové" programovací postupy nepoužívám, ale dost často čtu v LWN/LKML, že někdo přepsal klíčový kus kernelu tak, aby fungoval "bezzámkově" - aby dobře škáloval na strojích s mnoha jádry. Bezzámkové programování jsem dříve vídal od programátorských diletantů, kteří, opojeni vícevláknovým během programu, nedospěli do ligy, kde se sluší používat zároveň také zámky (třeba Posixová zamykací primitiva) - takže jejich programy žraly 100% CPU v těsných bezzámkových smyčkách a dělaly "divné" věci, na které jejich autoři jenom bezradně zírali. Dnes si myslím, že bezzámkové vícevláknové programování je potenciálně užitečná věc právě kvůli škálování výkonu, ale je to zrádné koření vyhrazené pro největší mistry magie, v nepovolaných rukou nebezpečné (bez ohledu na zde probíranou "vlastnost" GCC).
• Zdálo by se, že se jedná pouze o problém obskurní architektury IA64 - tzn. nikoli třeba x86_64. Takže by to "většinová programátorská populace" mohla hodit za hlavu... ovšem v tom případě by zhřešilé "většinové" programy nefungovaly správně na dnešní IA64, a navíc co dnes není, může za pár let klidně dorazit i na x86_64...
• "Problém" s asynchronním přístupem do dat v rámci interruptu je v tomto kontextu irelevantní - ví se o něm, jde o principiální záležitost, jsou k tomu určena zamykací primitiva, v Linuxu se netýká user space, stejně tak se IMO netýká jazyka C (úplně jiná vrstva abstrakce - nemůžete chtít po programovacím jazyku typu "lepší assembler", aby nějak implicitně řešil interrupty, které vyžadují spoustu explicitního HW-specifického ošetření). Kdo píše obsluhy interruptů, měl by vědět, co dělá. (Zmíněná "skoro-atomická" instrukce IA64 je pravděpodobně vůči interruptu atomická.)
• Pokud je ta "skrytá manipulace s dvěma proměnnými zároveň" věcí výkonové optimalizace, spíš než "jinak to na dané architektuře nejde", slušelo by se, aby ta optimalizace šla vypnout nějakou cmdline opšnou GCC...

[little.owl]

GCC v této operaci nepředpokládá, že by program mohl běžet paralelně ve více vláknech na více jádrech.

To neni chyba gcc, ale vlastnost C[99]; teprve novy standard prinasi thread model.

Ohledne interruptu souhlas, to jde uplne mimo a C nabizi alespon neco (sig_atomic_t).

Zverstva s bitovymi poli je jeden z duvodu, proc je kernel nezkompilovatelny jinym kompilatorem nez gcc, protoze to v mnoha pripadech narazi implementation-defined chovani.

[Martin Mareš]

To neni chyba gcc, ale vlastnost C[99]

Ne, je to vlastnost GCC, která sice není formálně v rozporu se standardem, ale je v rozporu se zdravým rozumem.

[Martin Mareš]

Dnes si myslím, že bezzámkové vícevláknové programování je potenciálně užitečná věc právě kvůli škálování výkonu, ale je to zrádné koření vyhrazené pro největší mistry magie, v nepovolaných rukou nebezpečné (bez ohledu na zde probíranou "vlastnost" GCC).

Tak jest.

Zdálo by se, že se jedná pouze o problém obskurní architektury IA64 - tzn. nikoli třeba x86_64.

Nikoliv, problém byl už pozorován i na amd64.

Pokud je ta "skrytá manipulace s dvěma proměnnými zároveň" věcí výkonové optimalizace, spíš než "jinak to na dané architektuře nejde", slušelo by se, aby ta optimalizace šla vypnout nějakou cmdline opšnou GCC...

Ona to vůbec není výkonová optimalizace, nýbrž artefakt velmi obskurní implementace bitfieldů, která se chová jinak, než autoři zamýšleli, a není podle všeho snadné ji opravit. Spíš ji bude potřeba celou přepsat.

[little.owl]

... velmi obskurní implementace bitfieldů ...

Nemyslim.

Na bit-fieldech je zajimave, ze na ne jsou minimalni pozadavky. Na stranu druhou to dava ohromnou flexibilitu, muzete pretypovat pointer na pointer na zapakovany bit-field a zpracovavat data, definovat vlastni binarni typy ci mapovat obskurni periferie.

[Martin Mareš]

Zrovna s tím mapováním obskurních periferií to není tak žhavé, protože pořadí bitfieldů ve struktuře není zaručeno. (A dokonce i samotné GCC je na big-endian a little-endian architekturách skládá opačně.)

A mohu sice dělat ledacos, ale efektivní to ve většině případů moc nebude. Asi neznám překladač, který by operace s bitfieldy uměl slušně optimalizovat.

[pc2005]

Zrovna s tím mapováním obskurních periferií to není tak žhavé, protože pořadí bitfieldů ve struktuře není zaručeno.

A to jsem se ty bitfieldy jak blbec učil používat na PIC24 .

[little.owl]

Jsou to treba in-house kompilatory pro specializovane procesory pouzivane v SoC. Tam se bojuje o kazdy bit. Namatkou Broadcom ci Imagination Technologies (PowerVR), ale i dalsi, v podstate kazdy velky vendor je ma a pouzivaji se v milionech zarizeni.

[Kvakor]

Pamatuju na jeden článek o threadech a synchronizaci, kde doporučovali dávat volatile proměnné jen samostatně, nikdy jako součást struktury, i když tam nebylo uvedeno proč přesně. Tenkrát jsem si říkal, že je to asi kvůli tomu, aby překladač nebral jako volatile celou strukutu, ale jak teď vidím, pravý důvod je mnohem děsivější.

[Michal Kubeček]

Uživatelé neustále dokazují, že neví, jak souborový systém funguje

nevědí

[2X4B-523P]

to asi Buzková nestihla zjednodušit

[David Watzke]

Dík, opravil jsem to.

[Virteal]

Hlavne od Ubuntu 10.10 vubec nic nefunguje, takze zlaty jadro 2.6. V 10.04 mi fungovalo bluetooth, dokonce i usb webkameru jsem rozjel, ac jsem v to neveril, tam proste fungovalo vsechno (aspon u me). No ale pak jsem udelal chybu a presel na 10.10. A do 11.10 se nic nezmenilo. Btusb mi byl cert dluznej. Webkamera taktez z pochybneho duvodu nereaguje, v 10.04 vse v poradku. Aspon ze funguje externi hadr a fleska.

[pc2005]

Je dost pech, že pokud chceme atomický bity, tak musej mít velikost nejmenší atomické proměnné (což je skoro vždy víc než jeden bit) .

[kralyk z abclinuxu]

No tak chtít po HW, aby umožnilo atomický přístup k jednotlivým bitům, by imho bylo hodně drastické...

[pc2005]

TMS34010: Ale zas ani tak ne . Sice to taky neumí, ale má nejblíž.

[whata]

Ona to umí v principu i x86 a v podstatě všechny SMP architektury. x86 stačí před relevantní instrukci napsat lock (lock xor mem, 1<<bit), u ostatních pak cyklus:

do {
        orig_val = *mem;
        new_val = orig_val|(1<<bit);
} while (!compare_and_swap new_val, orig_val, mem);

(případně lehce modifikovaný pro load/store exclusive architektury)

[little.owl]

To je jen workaround s lockovanim, ale pro "cistokrevne" reseni potrebujete bitovou adresaci, coz umi vetsinou jen silne specializovany exoticky HW.

[Luchik]

Přečetl jsem si tu diskuzi kolem bitfieldů, celkem jsem (snad) pochopil názor Little.Owl. Podívejme se na variantu, kdy bitfieldy ve struktuře jsou.

Otázka zní, do jaké "storage unit" se ukládají bitfieldy. Já měl vždy "tak nějak intuitivně" za to, že pokud jsou bitfieldy ve struktuře, můžou být uloženy "skoro" kdekoliv, ale jejich storage unit by měla být oddělena od storage unit ne-bitfieldových členů struktury.

Zajímalo by mě, jestli to teda standard upřesňuje více, nebo ne. Předpokládám, že podle Little.Owl ne, čili storage unit může dohromady nést bitfield i ne-bitfield, což by vysvětlovalo, proč GCC na IA64 v jednom 64bitovém storage unit neslo jednu proměnnou typu int32 a jeden bitfield.

Lze ve starším standardu (řekněme klasicky ANSI89) vidět něco o těch storage units ?

[Martin Mareš]

Zajímalo by mě, jestli to teda standard upřesňuje více, nebo ne.

Z toho, co říká o reprezentaci elementárních typů, plyne, že storage units nemohou být mezi různými proměnnými (či položkami struktur) sdílené, s výjimkou toho, že jednu storage unit může sdílet více bit-fieldů.

Jinak i na IA64 je storage unit 8 bitů.

Lze ve starším standardu (řekněme klasicky ANSI89) vidět něco o těch storage units ?

Myslím, že prakticky totéž, co v C99.

[Luchik]

Aha, dobřе. Pak ale nerozumím, proč to na tom IA64 (bitfield i s integerovou členskou proměnnou) načetl naráz jako jeden 64bitový integer.

Je možné, že zde míchám dvě věci, že standard hovoří o tom, jak je to uloženo, nikoliv jak se s tím pracuje - tedy to, že standard nezakazuje, aby se naráz načetlo více storage units, ale spíše vynucuje, aby se neporušila atomicita nějaké storage unit.

I pokud by tomu tak bylo, tak má člověk z toho takový nepříjemný pocit, že člověk očekává, že se bude v paměti pracovat jen s těmi storage units, na jejichž proměnné se v C kódu sahá.

Znamená to tedy, že synchronizačními funkcemi (např. v pthreads) musím pokrýt operace ve struktuře častěji než bych chtěl, jelikož se nelze vyvarovat toho, že kompilátor sáhne i na jinou storage unit, než by šlo explictně usoudit z mého C kódu.

Ale to už se tady asi propíralo (a nejsem z toho chytrý :) ).

[Filip Jirsák]

standard hovoří o tom, jak je to uloženo, nikoliv jak se s tím pracuje

To je podle mne právě ten problém, který znemožňuje ve vícevláknových aplikacích spoléhat se jen na standard. U jednovláknové aplikace skutečně stačí vědět, jak je to uložené. U vícevláknové to už ale nestačí a je potřeba vědět i to, jak se s tím pracuje - respektive musíte mít nějaká rozumná omezení toho, jak se s tím pracovat může.

Znamená to tedy, že synchronizačními funkcemi (např. v pthreads) musím pokrýt operace ve struktuře častěji než bych chtěl, jelikož se nelze vyvarovat toho, že kompilátor sáhne i na jinou storage unit, než by šlo explictně usoudit z mého C kódu.

Pokud tahle možnost vyplývá jenom z toho, že nikde ve standardu není napsáno, že při práci s bitovým polem kompilátor nesmí sáhnout i na vedlejší bajty, pak to není omezené jen na struktury. Protože stejně tak nejspíš není ve standardu napsáno ani to, že při práci s jakoukoli jinou proměnnou nesmí kompilátor sáhnout na vedlejší (nebo jakékoli jiné náhodné) bajty. Kdyby to totiž ve standardu explicitně pro různé proměnné uvedeno bylo a pro bitová pole ne, dá se z toho celkem jednoduše odvodit, že pro bitová pole tuto možnost standard připouští a že chyba je jednoznačně na straně jádra. A to se myslím nestalo.

[little.owl]

Uprimne, cetl jsem ho cele jiz dvema roky, ale zhrnul bych to takto.

Standard pracuje na atomicke urovni se dvema typy objektu:

1. slozene z bytu
2. slozene z bitu

Objekty slozene z bytu se reprezentuji jako posloupnost bytu, kde byte == unsigned char.

Objekty slozene z bitu se ukladaji do storage units, protoze se nevyzaduje bitova adresovatelnost. Ulozeni je implementacne zavisle.

Byte je sklada z bitu a jejich pocet je CHAR_BIT.

Objekty slozene z bytu jsou char, int, long ... etc. Vnitrni bitova reprezentace je take implementacne zavisla.

Protoze i objekty slozene z bytu maji implementacne zavislou bitovou reprezentaci, lze je implementacne zavisle ulozit do storage unit.

Standard neresi otazku jak ulozit storage unit do struktury, ale vyplyva z nej, ze standardni strukturu jako posloupnost bytu s bitovou reprezentaci lze ulozit do storage unit.

Jinak receno, storage unit je pytel na bity a lze do nacpat cokoliv co ma bitovou reprezentaci, tady vlastne vsechno.

Velikost storage unit musi splnit podminky:

• adresovatelna - tim dana minimalni velikost (na PC 8 bitu)
• dostatecne velka na to, aby ulozila data

Bit-fields se syntaxi:

struct test {
  unsigned:2;
  unsigned:0;
  unsigned:1;
}

jsou jedina moznost, jak programator muze vytvorit bitovy objekt. Kompilator ho vezme a implementacne zavislym zpusobem ho ulozi do implementacne zavisle storage unit.

[Martin Mareš]

Přečetl jsem si to pro jistotu ještě jednou.

O "addressable storage units" standard hovoří pouze ve dvou kontextech. Jednak říká, že posloupnost po sobě jdoucích bit-fieldů se uloží do posloupnosti po sobě jdoucích storage units. A pak specifikuje, že byte je "addressable unit of data storage" složená z CHAR_BIT bitů. Vše ostatní je už definováno pomocí bytů, speciálně sekce 6.2.6.1 říká: "Except for bit-fields, objects are composed of contiguous sequences of one or more bytes."

O storage units, do nichž se ukládají bit-fieldy, se nikde neříká nic konkrétního. Speciálně standard nespecifikuje, v jakém vztahu jsou tyto units s byty. Možnost, že by v jedné takové storage unit byl uložen současně bit-field a něco jiného, není nikde explicitně zmíněna.

[little.owl]

Konecne doma a ted tohle ... jste take nezmar.

O storage units, do nichž se ukládají bit-fieldy, se nikde neříká nic konkrétního. Speciálně standard nespecifikuje, v jakém vztahu jsou tyto units s byty.

Ano. V pre-ANSI verzi C byly standardni typy povazovany take za bit-field types, ktere ale maji nejaky format, a po zavedeni verze se struct to bylo vypusteno, s tim ze je to plne interni vec kompilatoru a platformy. Reziduum je ze muzete u bit-fields sice psat normalni typ, ale je to fakticky k nicemu. Vztah mezi units a byty neni asi potreba; vy jako programator nemate moznost ulozit cokoliv do storage unit a navic ani nevite jak je to tam ulozeno.

Spise je lepsi rozumet, co se podle standardu stane pri kombinaci normalnich typu a bit-fields. Podle mne to vyplyva to z pozadavku na struktury a take z toho jak je definovan korektni alignment.

Chapu to tak, ze je to cyklus, kde se zacina od prvniho az do posledni deklarovaneho clenu. Pokud je to normalni typ s alignmentem umisti se clen na prvni vyssi zarovnanou adresu. Pokud je to bitfield, umisti se jeho storage unit za predchozi clen, zadny alignment neni garantovan, storage unit musi byt adresovatelna a bitfield se tam musi vejit. Pokud je nasledujici clen opet bit-field, muze byt ulozen do predchozi storage unit.

Dale, protoze u storage unit se nebere ohled na alignment, muze se umistit do pozice, kde by normalne byly padding bytes nutne pro alignment nasledujiciho typu. Proto se zavadi i unnamed bit-fields, ktere lze pouzit pro vynuceni memory layoutu:

struct test {
  uint32_t   a;
            :5;
  uint32_t   b;
            :5;
            :0;
  unsigned c:5;
};

Sirka :0 zde znamena otevri novou storage units, nevkladej do predchozi (takze predchozi storage unit je doplnena padding bity).

S takovym memory layoutem nemate moznost diskretniho cteni. To se muzete pokusit zlepsit zarovnavanim storage unit, ale stejne nevite kolik je tam bit-fields. A kdyz umistite jeden bit-field do jedne storage unit a ty zarovnate, nema smysl to vubec pouzivat, kdyz vam to prida k 1b dalsich 7b. Pak je lepsi normalni uint[8,16,32]_t, kdy vite jak to vypada uvnitr a bity si vymaskujete.

Pokud nekdo pouziva tenhle implementacne zavisly neportovatelny hybrid, tak par povolenych a beznych side effectu mezi sequence points pri zapisu nebo cteni by ho nemelo prekvapit. A opet, protoze adresace bitfields nefunguje, chapu gcc, ze precetlo cele slovo do registru a bity, co potrebovalo si vymaskovalo, nejjednoduzsi a nejrychlejsi a u nekterych instrukcnich sad a memory layoutu jedine mozne.

Jak to ovlivni volatile, nevim, asi se tam vlozi padding.

[Martin Mareš]

Dale, protoze u storage unit se nebere ohled na alignment, muze se umistit do pozice, kde by normalne byly padding bytes nutne pro alignment nasledujiciho typu.

Zde se skrývá jádro pudla. Souhlasím s Vaším popisem toho, jak se struktury skládají do paměti, ale neshodujeme se v tom, jaké to má důsledky.

Nemyslím si, že by z citovaného pravidla cokoliv plynulo o chování předchozího nebo následujícího (nebo jakékoliv jiného) prvku struktury. Po storage units obsahujících bit-fieldy se tak jako tak musí objevit správné množství paddingu tak, aby byl následující prvek správně zarovnán. Chování předchozího prvku by nemělo být ovlivněno čímkoliv, co leží za ním, protože je beztak správně zarovnán.

Problémy mohou nastat jedině v případě, kdy je předchozí prvek typu, k němuž nelze přistupovat přímo, a překladač se musí uchýlit k read-modify-write. Například stará Alpha 21164 neuměla přímo přečíst nic menšího než 32 bitů, takže ve struktuře

struct xyz {
   char a;
   int b:4;
}

by zápis do a přečetl a zapsal i b. Jenže to by se stalo i tehdy, kdyby b nebyl bit-field, ale char.

[Mimochodem, ono tohle chování charů na Alphě je vůbec poněkud na hraně korektnosti: lze opravdu považovat za "addressable storage unit" něco, co nelze změnit samostatně?]

Sečteno a podtrženo:

• Standard nikde výslovně negarantuje, že přístup k jedné hodnotě nemůže mít jako side-efekt přístup k nějaké jiné hodnotě. Překladač má právo provést s kódem cokoliv, co (v mezích execution modelu) nezmění jeho chování.
• Jelikož execution model Céčka nepočítá s žádným asynchronním vykonáváním kódu (kromě signálů), je legální přečíst a zapsat nesouvisející hodnotu, nebo dokonce ji i změnit a pak zase uvést do původního stavu.
• Součástí Unixové kultury nicméně je, že překladač "nedělá nepředloženosti", tedy zřetelně nelogické věci, leda by byly vynuceny vlastnostmi hardwaru. Speciálně POSIX Threads nemohou bez předpokladu, že se do nesouvisejících hodnot nezapisuje, vůbec fungovat. Takže pokud se překladač chce tvářit jako součást POSIXového systému, neměl by se toho dopouštět.
• Nevidím jediné místo ve standardu, které by nás opravňovalo myslet si, že se přítomností bit-fieldů cokoliv změní. Kdyby na místě bit-fieldu byl char, všechny jevy, které popisujete, mohou nastat také.

Jsou chvíle, kdy bych si přál, aby naše svaté knihy byly o něco úplnější... :)

[pc2005]

Uf to už bych radši (jako kompiler) ukládal každý char do 32bit slova. Opravdu neměla masku na jednotlivé bajty?

[Martin Mareš]

Původní Alpha 21164 neměla, až v 21164A přibyly instrukce na přístup k 8-bitovým a 16-bitovým datům.

[little.owl]

Po storage units obsahujících bit-fieldy se tak jako tak musí objevit správné množství paddingu tak, aby byl následující prvek správně zarovnán.

Ano, pokud nasledujici prvek neni storage unit, ale o tom zde nebyl nikdy spor.

U bitfieldu vam nic nezarucuje ani to, ze storage unit ma velikost byte; pokud chcete automaticky zajist garantovane "chovani bez predlozenosti", musite fakticky zajistit jejich primou adresovatelnot metodou pointer+offset, coz se nevyzaduje a pak ztratite duvod je pouzivat, nebot uz nebudou mit co nabidnout oproti jinym typu.

[Mimochodem, ono tohle chování charů na Alphě je vůbec poněkud na hraně korektnosti: lze opravdu považovat za "addressable storage unit" něco, co nelze změnit samostatně?]

Dopad takovych HW limitaci je bezna vec. U struktury a bit-field je to asi OK, ono se rozlisuje mezi "mit adresu" a "byt adresovatelny". Prvni znamena pristup pointerem, druhy ze pomoci nejake adresy se k tomu kompilator dostane a bity nejakym kodem vyextrahuje. Vam je stejne primy pristup k nicemu, nevite jak storage unit uvnitr vypada. U objektu mimo strukturu by to byl jiste bug.

Nevidím jediné místo ve standardu, které by nás opravňovalo myslet si, že se přítomností bit-fieldů cokoliv změní. Kdyby na místě bit-fieldu byl char, všechny jevy, které popisujete, mohou nastat také.

Ne, ne, ne. Alingment of storage units je vyslovne uvaden jako unspecified behavior, cejch vyvrhele (i v Annex J), coz fakticky o bit-fieldech rika: programatore, pokud se ti bit-fields na jedne platforme a kompilatoru chovaji nejak, nepocitej s tim, ze na jine to bude stejne a pokud na to spolehas, tvuj program nemusi vubec fungovat. Hure, ono se to muze chovat jinak i pokud jen zmenite zdanlive nesouvisejici parametry stejneho kompilatoru pro stejnou platformu (treba gcc -O2). U charu nic takoveho nemate, dokonce bych rekl, ze char-y jsou implicitne portabilni a konzistentni vzdy a vsude. Char a bit-field jsou nebe a dudy.

Cokoliv s bitfields, je spise zalezitost dobre viry. BTW, u safety & security review-ovaneho kodu s bitfields se akceptuji jen konstrukce jako

union PORT {
       struct {
               volatile unsigned : 25;
               volatile unsigned cc : 5;
               volatile unsigned bb : 1;
               volatile unsigned aa : 1;
       } bitfields;
       volatile uint32 reg;
};

a jen proto, ze to jinak nejde. Tim si trochu vynutite ono "chovani bez predlozenosti", s vyjimkou indianness. Pokud ne, je treba tvure kompilatoru bit, tlouci a mlatit dokud to neopravi.

Speciálně POSIX Threads nemohou bez předpokladu, že se do nesouvisejících hodnot nezapisuje, vůbec fungovat.

POSIX standard nevyzaduje od kompilatoru vice nez ISO C kompatibililtu; ale netreba plakat, C11 to resi.

[Martin Mareš]

Přijde mi, že každý mluvíme o něčem úplně jiném.

Já se snažím celou dobu mluvit o (ne)možnosti přístupu k nesouvisejícím hodnotám, což je jev, kterým celá tato diskuse začala.

Nikde nevyvracím, že bit-fieldy mají chování takřka úplně závislé na implementaci a že do toho, jak jsou uloženy, mi, pokud ctím standard, vůbec nic není. Jediné, co se snažím tvrdit, je, že jejich přítomnost nemá co mít vliv na to, jak se chovají non-bit-field prvky struktury. Vy se tváříte, že může, ale dosud jste neřekl jediný argument, proč by tomu tak mělo být, a jenom dokola opakujete, že reprezentace bit-fieldů je nespecifikovaná.

POSIX standard nevyzaduje od kompilatoru vice nez ISO C kompatibililtu;

Standard výslovně ne, prakticky libovolné jeho použití ano. Nechť v programu deklaruji

int i;
int j;

a spustím dvě vlákna, z nichž jednou bude používat jen proměnnou i a druhé jen j. Podle C99 je zcela korektní, aby překladač do kódu prvního vlákna přidal "j++; j--;. Ovšem běh programu to zcela rozbije.

[little.owl]

Podle C99 je zcela korektní, aby překladač do kódu prvního vlákna přidal "j++; j--;.

Neni to korektni pokud pouzijete volatile, ale jak uz jsme rekli, volatile diky nedostatecnym memory fence multithreading neresi. Pri optimalizaci na rychlost se osklive triky bezne delaji, naucte se s tim zit.

Minuly rok jsem byl na prednasce o C++11 a byli tam i jeho tvurci ze standardizacni komise. A prvni recnicka otazka byla, jestli vime, co je nejbezpecnejsi vec na svete. Odpoved: dva language lawyers v jedne mistnosti, a my jsme tady ctyri.

Pomalu bych to ukoncil. Diky za diskuzi a nekdy jindy.

[Martin Mareš]

Také díky.