Cześć.

Jest sobie proces A.

W środku procesu A działają threads: T1 i T2.

Załóżmy że maszyna nie jest niczym zajęta i ma 2 fizyczne rdzenie.

T1 pisze do rury.

T2 czyta z rury.

W tej chwili T2 jest zablokowany na read na rurze.

T1 wkłada bajt do rury.

Jak szybko T2 zostanie wznowiony? Sa to dwa pytania: jak szybko
informacja w rurze wyleci na zewnatrz i jak szybko wątek T2 ruszy.

Pytanie jest z gatunku ogolnych ponieważ chce wiedziec jak szybko moge
się spodziewać wznowienia we współczesnych systemach operacyjnych. Tu i
tam pobąkują że np. Windows jets w stanie przełaczyć kilkaset razy na
sekunde kontekst wątku. Tylko że to dotyczy chyba ich ciaglej pracy. A u
mnie t1 wsadził do rurki i, jesli moje urojenia są prawdziwe, T2
powinien zostać wznowiony natychmiast (np. na drugim core). Chciałbym
wiedziec jak oszacować to "natychmiast".

Moge napisac przykład. Ale może ktoś wie od ręki jak dziala OS (Win/Lin)
w takiej sytuacji.

Opcja ekspercka: a co jeśli T1 jest w procesie A a T2 w procesie B?
Procesor ma 2 cory, w systemie cisza. Czy strace czas na jakiś switch
contextu? Urojenie jest takie że OS mógłby trzymac w gotowości Proces B
ja wolnym core i nie powinno być spowolnień vs dwa wątki w jednym procesie.

do góry

On Tuesday, March 20, 2018 at 10:26:15 PM UTC+1, Sebastian Biały wrote:
> [...]
> Moge napisac przykład. Ale może ktoś wie od ręki jak dziala OS (Win/Lin)
> w takiej sytuacji.

Głowy nie dam, ale obawiam się, że nie otrzymasz tak precyzyjnej
odpowiedzi, która uchroniłaby Ciebie przed pisaniem testów. Nawet
jakbyś dostał tak precyzyjną odpowiedź, to nie wiem czy jesteś pewny
co do nakładu obliczeń swojego oprogramowania. Podsumowując: jeśli to
co robisz jest ważne i jeśli działaś 'na krawędzi' - czyli wykonujesz
relatywnie mało operacji względem operacji na rurkach/wątkach, to i
tak i tak czeka Ciebie kilka prób i pomiarów czasu.

> [...]

Pozdrawiam

do góry

Sebastian Biały <h...@p...onet.pl> wrote:

> Jak szybko T2 zostanie wznowiony?

Nie ma na to żadnej gwarancji. Ani Windows ani Linux nie są OS-ami czasu
rzeczywistego, a nawet jakbyś miał tylko te dwa procesy w systemie i
żadnego innego (nawet init), to i tak kernel robi różne rzeczy i
potrzebuje do tego procesora.

> Moge napisac przykład.

Spróbuj, pokesperymentuj też z sched_setaffinity.

http://man7.org/linux/man-pages/man2/sched_setaffini
ty.2.html

--
[ Email: a@b a=grp b=chmurka.net ]
[ Web: http://www.chmurka.net/ ]

do góry

Dnia Tue, 20 Mar 2018 22:25:53 +0100, Sebastian Biały napisał(a):

> Jak szybko T2 zostanie wznowiony? Sa to dwa pytania: jak szybko
> informacja w rurze wyleci na zewnatrz i jak szybko wątek T2 ruszy.

Odpowiedź: Wątek T2 ruszy wtedy, gdy OS znajdzie czas, żeby go przełączyć.
Nie wcześniej, i nie później.

Ten czas możesz co najwyżej zgrubnie oszacować, bazując na statystyce
(czyt. "w 80% przypadków, będzie to krócej, niż X"), ale nigdy nie będziesz
go pewien.

--
Yakhub

do góry

> Jak szybko T2 zostanie wznowiony? Sa to dwa pytania: jak szybko
> informacja w rurze wyleci na zewnatrz i jak szybko wątek T2 ruszy.

To jest jedno pytanie, bo pierwsze nie ma sensu w oderwaniu od drugiego.

> Pytanie jest z gatunku ogolnych ponieważ chce wiedziec jak szybko moge
> się spodziewać wznowienia we współczesnych systemach operacyjnych. Tu i
> tam pobąkują że np. Windows jets w stanie przełaczyć kilkaset razy na
> sekunde kontekst wątku.

Etam. Dwa procesy komunikujące się na tym samym pececie przez lokalne TCP są w stanie
przesłać 10000 komunikatów na sekundę właśnie w ten sposób (nie ma powodu, żeby
lokalne TCP było szybsze, niż rura). Po drodze dzieje się mnóstwo innych rzeczy, niż
samo pisanie i czytanie, więc da się to odchudzić i jeszcze przyśpieszyć.
Bardzo łatwo jest to zmierzyć, napisz pętlę i weź do ręki zegarek.

> Tylko że to dotyczy chyba ich ciaglej pracy. A u
> mnie t1 wsadził do rurki i, jesli moje urojenia są prawdziwe, T2
> powinien zostać wznowiony natychmiast (np. na drugim core). Chciałbym
> wiedziec jak oszacować to "natychmiast".

Nie ma czegoś takiego jak "natychmiast", jeśli coś jest gdzieś indziej.
Natomiast możesz rozważyć dwa przypadki:

1. T1 pisze, T2 czyta i tak w kółko
2. T1 pisze, T2 czyta, T2 pisze, T1 czyta, i tak w kółko

Różnica jest taka, że jeśli T1 tylko pisze, to może napisać dwa komunikaty zanim T2
odczyta pierwszy. To nie jest problemem jeśli T2 rozróżnia granice między
komunikatami, ale może spowodować, że T2 obudzi się tylko raz i za jednym odczytem
pobierze wszystkie dostępne dane (czyli dwa komunikaty). To zakłóci pomiar, bo ilość
komunikatów nie będzie równa ilości wybudzeń.
Drugi scenariusz (ping-pong) zapewnia, że komunikaty są pisane i czytane pojedynczo.
Pierwszy scenariusz może być szybszy w sensie throughput, co zwykle jest korzystne.

> Opcja ekspercka: a co jeśli T1 jest w procesie A a T2 w procesie B?

Też trzeba zmierzyć.

--
Maciej Sobczak * http://www.inspirel.com

do góry

On 3/26/2018 11:52 AM, Maciej Sobczak wrote:
> Etam. Dwa procesy komunikujące się na tym samym pececie przez lokalne TCP są w
stanie przesłać 10000 komunikatów na sekundę

Kiepsko. Jesteś pewien że masz TCP_NODELAY?

> Bardzo łatwo jest to zmierzyć, napisz pętlę i weź do ręki zegarek.

Jestem wrogiem statystcznych benchmarków z gatunku for( i = 0 ; i <
10000000 ... bo są nic nie warte w praktyce.

Ja tak naprawde pytam o internalne dzialanie systemu operacyjnego.

Np. swego czasu w windowsie był lub jest taki algorytm który jesli watek
zawiesi się na wait to inny watek wykorzystuje jego pozostałą cześć
slotu czasowego. Zakładając że byłby od wybrany sprytnie, czyli akurat
ten który dane ma odebrać było by to szybsze niż czekanie na nastepną
rundę. A może można pomóc wskazując jaki inny watek miałby się obudzić
kiedy ja zrobie wait. A może trzeba robić spinlocki zamiast czekać
biernie na wyjście z read. A może porzucić rury na rzecz jawnego shared
memory bo nie mają sensu. itd itp. Jestem pewny że ktoś już to wczesniej
obadał i wie jak zrobić to sensownie szybko.

do góry

On 3/26/2018 9:24 AM, Yakhub wrote:
>> Jak szybko T2 zostanie wznowiony? Sa to dwa pytania: jak szybko
>> informacja w rurze wyleci na zewnatrz i jak szybko wątek T2 ruszy.
> Odpowiedź: Wątek T2 ruszy wtedy, gdy OS znajdzie czas, żeby go przełączyć.
> Nie wcześniej, i nie później.

Pytam o średni czas obserwowany w aplikacjach.

> Ten czas możesz co najwyżej zgrubnie oszacować, bazując na statystyce
> (czyt. "w 80% przypadków, będzie to krócej, niż X"), ale nigdy nie będziesz
> go pewien.

Nie musze być pewien, przesylam miliony małych komunikatów w czasie
życia aplikacji, chcę mieć wyłącznie pogląd statystyczny o jakich
czasach mówimy we współczesnych systemach operacyjnych i co mozna zrobić
aby te czasy redukować.

do góry

On 3/21/2018 1:26 PM, Adam Wysocki wrote:
>> Jak szybko T2 zostanie wznowiony?
> Nie ma na to żadnej gwarancji.

Nie pytam o gwarancje, nie pisze apliakcji RT.

> Spróbuj, pokesperymentuj też z sched_setaffinity.
> http://man7.org/linux/man-pages/man2/sched_setaffini
ty.2.html

Misiałbym wczesniej chyba miec pojęcie o tym jak działa algorytmika
schedulera wątków i procesów. To troche spory temat na samodzielne
przegryzanie się.

do góry