Sdílený zdroj ==Spor
Zápis do normálního souboru podle definice je serializovaná operace. Nezískáte žádný výkon pokusem o zápis z více vláken, I/O je omezený zdroj s řádově menší šířkou pásma než i ten nejpomalejší nebo nejvíce přetížený CPU.
Souběžný přístup ke sdílenému zdroji může být komplikovaný (a pomalý)
Pokud máte více vláken, která provádějí drahé výpočty, pak máte možnosti, pokud používáte více vláken, protože si myslíte, že něco urychlíte, uděláte pravý opak. Soupeření o I/O vždy zpomaluje přístup ke zdroji, nikdy jej nezrychluje kvůli čekání na zámek a další režii.
Musíte mít kritickou sekci, která je chráněna a povoluje pouze jeden zapisovač najednou. Stačí vyhledat zdrojový kód libovolného zapisovače protokolů, který podporuje souběžnost, a uvidíte, že do souboru zapisuje pouze jedno vlákno.
Pokud je vaše aplikace primárně:
-
CPU Bound: Můžete použít nějaký zamykací mechanismus/konstrukci dat, abyste nechali do souboru zapisovat pouze jedno vlákno z mnoha najednou, což bude z hlediska souběžnosti jako naivní řešení k ničemu; Pokud jsou tato vlákna vázána na CPU s malým I/O, mohlo by to fungovat.
-
I/O Bound: Toto je nejběžnější případ, musíte použít systém předávání zpráv s nějakou frontou a nechat všechna vlákna odeslat do fronty/vyrovnávací paměti a nechat z ní stáhnout jediné vlákno a zapisovat do souboru. Toto bude nejvíce škálovatelné a nejsnáze implementovatelné řešení.
Ukládání do deníků – Async Writes
Pokud potřebujete vytvořit jeden super velký soubor, kde pořadí zápisů není důležité a program je vázán na CPU, můžete použít techniku žurnálování.
Nechte každý process zapsat do samostatného souboru a poté spojit více souborů do jednoho velkého souboru na konci. Toto je velmi stará škola nízké technologie řešení, které funguje dobře a funguje po desetiletí.
Je zřejmé, že čím více I/O úložiště máte, tím lépe to bude fungovat na konci concat.