> 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