> Zadanie 7. Wątki nie są panaceum na problemy z wydajnością oprogramowania na **maszynach wieloprocesorowych. ze współdzieloną pamięcią (Shared Memory Processors)**. Wymień warunki jakie musi spełniać architektura programu by stosowanie wątków było uzasadnione (§4.3)? Co ogranicza wydajność programów używających wątków? Jakie problemy z efektywnym użyciem wątków napotkali twórcy silnika gry [*Half-Life 26](https://arstechnica.com/gaming/2006/11/valve-multicore/)* i jak je rozwiązali?

**Shared Memory (multi)Processors** - architektura, w któej każdy procesor łączy się z pamięcią przez memory access swticha ma:
1. taki sam overhead dostępu do dowolnego miejsca w pamięci bo połączone z centralną pamięcią przez bus
2. dostep do nielokalnej pamięci implikuje dodatkowy overhead dla każdego procesora (NUMA - Non Uniform Memory Access) bo mamy pamięć rozproszoną i to wszystko połączone siecią z access switchem.

Stosowanie wątków jest bez sensu jeśli jest to związane z jednym zasobem(dysk, CPU) i każdy wątek próbowałby tylko wykorzystać ten zasób - jedyne co byśmy mieli to stratę na czasie przy zmianie wątków. Np. program listujący wszystkie pliki na dysku: równlolegle to by głowica dysku oszalała zamiast poruszać się regularnie. Tak samo z programem który, robi jakieś zadania w szeregu - każde kolejne zadanie wymaga poprzedniego stanu.
Uzasadnione może być kiedy mamy np. liczyć hashe plików - jeden wątek czytający dane, drugi liczący (bo można przyrostowo liczyć hash). Można je też stosować, jak mamy operacje które trwają potencjalnie długo a nie są jakieś krytyczne dla działania programu. Mozna np. mieć wątki osobne do przeszukiwania dwóch osobnych baz danych. UI powinno być na innym wątku, żeby nie nie zacinało. Nie używać wątków jeśli mają działać krótko. Używać jak nie skomplikują za bardzo programu a przyspieszą i wymiana informacji nie będzie bardzo kosztowna.

Ograniczenia efektywności wielowątkowych programów: potrzeba na separację pamięci - wewnętrzna wirtualizacja pamięci..

Valve:
    Postanowił napisać silnik tak, żeby korzystał z pełni potencjału wielu rdzeni procesora. Podzielili sobie wielowątkowe zadania na 3 kategorie:
    1. coarse(duże) - duże systemy np. AI, rendering na osobnych wątkach. Problemem jest np. silnik dźwiękowy, który 80% czasu czeka.
    2. fine-grained(drobne) - wiele podobnych zadań rozproszonych na wiele rdzeni, np. pętla która leci po tablicy może być podzielona na małe pętle na różnych wątkach. Problem jest jak niektóre zadania nie kończą się tak samo szybko jak inne.
    3. hybrid - połączenie dwóch powyższych w różnych przypadkach.

Cwaniaki pomyśleli, że trzeba napisać silnik tak, żeby używał jak najwięcej czasu procesora i korzystał dobrze z wielowątkowości.
nowy  potok renderowania:
1. stwórz listę scen do renderowania - np. odbicia wody, świat, ekrany w TV
2. Zrównolegl symulacje graficzne (liny, sprite, particles, cloth)
3. policz transformacje szkieletów postaci we wszystkich scenach równolegle.
4. policz cienie wszystkich postaci równolegle.
5. pozwól wielu wątkom rysować równolegle - trzeba było zmienić liba graficznego który żył nad Direct3D

było tak dużo multithreadingu, że trzeba było wymiślić mechanizmy synchronizacji. Przy starych było było za dużo deadlocków. Zrobili spin lock (aktywne czekanie while(flaga włączona){}) wykorzystujące nową instrukcję czekania w CPU zamiast mutexów. Wprowadzili semafory do kontroli zasobó (licznik kto chce się dostać - jak ==0 to wątek robi +1 i wykonuje operacje, a na koniec robi -1). Wprowadzili model 'wielu czyta jeden pisze' Bo około 95% czasu to było czytanie a 5% pisanie. Mają wątki główne i wątki mniejsze - wątki główne np. wątek postaci które spawnią mniejsze wątki np. liczący kości i wątek rysujący. Valve wprowadziło sobie też pulę wątków roboczych w głównej pętli gry (jak coś trzeba zrobić to zatrudniamy jednego 'robotnika' a po skończeniu pracy zwalniamy).