🚀 go-pugleaf

W dniu 2017-02-24 o 19:46, stchebel@gmail.com pisze:
> Witam,
>
>  Nigdy nie miałem potrzeby programowania wielowątkowego, aż tu nagle
>  pojawia się pewna koncepcja w moim projekcie. Chodzi o to, żeby jak
>  gdyby 2-wie różne maszyny zajmowały się równolegle 2-ma różnymi sprawami,
>  ale trzeba ich działania w/g pewnych założeń zsynchronizować. No więc
>  na chłopski rozum potrzebna jest trzecia maszyna kontrolująca synchronizację
>  2-ch pozostałych. Przykład: mamy tablicę a[1..N] i chcemy jak najszybciej
>  obliczyć sumę wszystkich elementów a[i].
>
> Wątek 1:
>
> Suma1:=0;
> for i:=1 to N/2 do
>  Suma1:=Suma1+a[i];
>
> Wątek 2:
>
> Suma2:=0;
> for i:=N/2+1 to N do
>  Suma2:=Suma2+a[i];
>
> Wątek 3:
>
> Jak zakończone jest działanie Wątków 2 i 3 , to finalnie
>
> Suma:=Suma1+Suma2;
>
> =====
>
> No i teraz pytania:
>
> 1) Co nam dają na czasie te 2 maszyny działające podobno równolegle?

Maszyny, czyli osobne komputery? Osobne procesy na jednym komputerze? 
Czy osobne wątki w ramach jednego procesu?
To są spore różnice, choć rozwiązania są ramowo podobne.

A co dają? Że posłużę się analogią, dają to co więcej pracowników w 
firmie, kosztują tyle że ktoś musi tym zarządzać.


>
> 2) Czy na maszynie 1-no rdzeniowej da się uruchomić więcej niż
>  1 wątek?  Jeżeli tak, to o co tu chodzi?

Oczywiście. Każda aplikacja aktualnie uruchamia zazwyczaj więcej niż 
jeden wątek.
Jak wejdziesz w menadżera zadań Windows, to w karcie Procesy możesz 
pokazać kolumnę Watki i pokaże Ci ile wątków ma dany proces.

Ograniczeniem jest liczba jednocześnie obsługiwanych wątków przez CPU. 
Jeszcze kilka lat temu 1 CPU obsługiwał jeden wątek na raz, co oznaczało 
że inne w tym czasie spały. To właśnie robi funkcja Sleep() - oddaje 
czas procesora innym wątkom.

Większość OSów to systemy z wywłaszczaniem - oznacza to że OS może w 
każdej chwili zatrzymać dany wątek, i wznowić inny. OS stara się dać jak 
najwięcej czasu każdemu wątkowi, I jak już wykorzystanie wątka CPU 
zbliża się do 100% to przydziela wątkom programów czas CPU w/g 
priorytetu wątku (i paru innych ustawień).

Między innymi dlatego jest ważne żeby dać znać procesorowi ze się nic 
nie robi, jak np. funkcja Sleep(), WaitForSingleObject() i inne, czy 
typowa pętla komunikatów (wątek GUI tam czeka aż OS wyśle komunikat, nie 
zużywając czasu CPU).

W dzisiejszych czasach większość procesorów ma przynajmniej dwa jądra, 
czyli obsługuje równocześnie dwa wątki, ale np Intel ma technologię 
HyperThreading gdzie jedno jadro jest w stanie obsłużyć dwa wątki na 
raz. Podobną technologię dodało AMD w swoich najnowszych procesorach, 
8-jądrowy procesor obsługuje jednocześnie 16 wątków.

Tego typu procesory są używane w serwerach, gdzie ilość wątków i 
wydajność energetyczna są ważniejsze niż prędkość pojedynczego wątku. 
Powoli także desktopy dostają obsługę większej ilości wątków na raz, i 
oprogramowanie desktopowe powoli się zmienia aby je wykorzystywać 
efektywnie.


> 3) Co polecacie z literatury sieciodostępnej celem zapoznania się z
>  tym tematem? Chodzi mi o jakieś praktyczne "etiudy" kilkuwątkowe.

Tematyka jest rozległa, radził bym najpierw poczytać jak to działa, co 
to są mutexy, semafory, operacje atomowe, bariery w pamięci, NUMA, i 
przede wszystkim dlaczego dostęp wielu wątków do tych samych danych musi 
być synchronizowany.

A kilka lat praktyki uczy jak nie używać tych rzeczy, uczy pokory, że 
łatwo coś zepsuć nie wiedząc nawet czemu ;-)

Generalnie najlepiej jest stosować gotowe obiekty przygotowane do pracy 
wielowątkowej (tu bieda w Delphi, jego RTLu i VCLu, poza TThreadList i 
chyba nic więcej). Najlepiej jest z góry rozdzielić pracę na wątki, tak 
aby nie współdzieliły danych, albo robiły to jak najkrócej.

Dobra jest też zasada że jakaś paczka danych należy tylko do jednego 
wątku - jak jest przesyłana do innego, to od tej chwili on jest za nią 
odpowiedzialny.


Jest też fajna rzecz, MapReduce, AFAIK opracowana w Google ponad 
dziesięć lat temu. Tu artykuł o tym: http://informatyka.wroc.pl/node/424
Google używa tego na petabajtach danych, tysiącach serwerów w klastrach, 
ale sama idea jest naprawdę prosta, wręcz genialnie prosta.

Np. Każde zapytanie do wyszukiwarki Google jest obsługiwane przez 
kilkanaście komputerów, które jednocześnie przetwarzają inne aspekty 
zapytania (szukanie w indeksach automatycznych, szukanie w indeksach 
ręcznych, reklamy, statystyki, etc), i dzięki podziałowi pracy robi to 
szybko.
Google pozwala sobie nawet zlecać tą samą pracę różnym komputerom (część 
Map z MapReduce), na wypadek gdyby któryś z nich nie był w stanie jej 
wykonać, lub wykonał ją zbyt powoli - wykorzystany zostanie wynik 
maszyny która skończyła pierwsza. Ich oprogramowanie nawet pamięta które 
komputery jak często się spóźniają, i może zgłaszać je do naprawy/wymiany.


Jak będziesz szukał informacji o wątkach, procesach i pracy równoległej, 
to nie skupiaj się na Delphi. To jest problem uniwersalny, a Delphi jest 
na tyle niszowe że dobrej literatury jest mało.

-- 
Arivald