::read i ::poll

heby

unread,

Nov 4, 2020, 4:32:00 AM11/4/20

to

Cześć.

Czytam z rurki za pomocą ::read. Blokująco, bo na tym polega
synchronizacja w tym konkretnym przypadku.

Ale muszę raz na jakiś czas stwierdzić, czy nie czas awaryjnie się
składać, obejrzeć jakas flagę, zawołać jakiś watchdog itd.

::read blokującego nie da się przerwać. Co prawda jest niby EINTR ale ja
czekam w wielu wątkach na wielu rurach i musze precyzyjnie przerwać
bardzo konkretny ::read, ten, a nie inny.

Rozwiązanie okazało się proste: użyć ::poll. Czeka on aż pojawią się
jakieś dane do odczytu, ale ma też timeout po którym zwraca mi
sterowanie i to załatwia temat przerywalnosci odczytu.

I wszystki super działa, tylko jest ... znacznie wolniejsze. Wywołanie
::read jest szybsze niż pary ::poll->::read. No i co z tym teraz zrobić?
Jest jakaś inna metoda na posiadanie blokującego ::read ale jednocześnie
możliwosci przerwania tego read na żądanie?

PS. Mogę zamknąc deskryptor pliku i wtedy ::read wylautuje z błedem. Ale
to jest nieeleganckie, ponadto nie dośc że powoduje race-conditions, to
jeszcze jest destrukcyjne, tzn komunikacja jest już niemożliwa do
wznowienia. A ja chce przerwać read, coś sprawdzić i wrócić do czekania
na dane.

michal....@bofc.pl

unread,

Nov 5, 2020, 5:45:08 AM11/5/20

to

On 2020-11-04 10:31:56, heby wrote:
> Rozwiązanie okazało się proste: użyć ::poll. Czeka on aż pojawią się jakieś
> dane do odczytu, ale ma też timeout po którym zwraca mi sterowanie i to
> załatwia temat przerywalnosci odczytu.
>
> I wszystki super działa, tylko jest ... znacznie wolniejsze. Wywołanie
> ::read jest szybsze niż pary ::poll->::read. No i co z tym teraz zrobić?
> Jest jakaś inna metoda na posiadanie blokującego ::read ale jednocześnie
> możliwosci przerwania tego read na żądanie?

signature.asc

heby

unread,

Nov 5, 2020, 6:57:08 AM11/5/20

to

On 05/11/2020 11:45, michal....@bofc.pl wrote:
> Najprościej będzie wysłać sygnał do konkretnego wątku przy pomocy
> pthread_kill(3).

Co z taką sytuacją:
{
...
std::mutex::scoped_lock lock(mutex);
...
::read(...)
}

Zakładając że zainstaluje globalny handler sygnałów (co już jest błędem
projektowym, może nie tylko ten wątek go potrzebuje), czy mogę wsyłać
coś co spowoduje że ::read wyskoczy z EINTR?

> Jak kod ma być przenośny między unixami, należy
> pamiętać by wyłączyć SA_RESTART na systemach z rodziny BSD przy
> pomocy siginterrupt(3).

No i tu właśnie jest problem. To ogromna apliakcja. Z powodu kilku
::read mam manipulować krytyczm, globlanym stanem aplikacji? Brzmi jak 1
z kolokwium z inżynierii programowania.

michal....@bofc.pl

unread,

Nov 5, 2020, 7:43:31 AM11/5/20

to

On 2020-11-05 12:57:04, heby wrote:
> On 05/11/2020 11:45, michal....@bofc.pl wrote:
> > Najprościej będzie wysłać sygnał do konkretnego wątku przy pomocy
> > pthread_kill(3).
>
> Co z taką sytuacją:
> {
> ...
> std::mutex::scoped_lock lock(mutex);
> ...
> ::read(...)
> }

Nic, w takim przypadku nie pomoże pthread_kill(3) tylko select/poll/epoll.

>
> Zakładając że zainstaluje globalny handler sygnałów (co już jest błędem
> projektowym, może nie tylko ten wątek go potrzebuje), czy mogę wsyłać coś co
> spowoduje że ::read wyskoczy z EINTR?

Globalny handler sygnałów nie jest błędem projektowym, błędne użycie go
jest błędem projektowym. Signal handler, którego jedyne zadanie to przerwać
syscall, może mieć jedynie 'return;' w body i nie musi operować na żadnych
danych. Każdy sygnał przerywa syscall, możesz wyemitować np. SIGUSR1. Ale
jeżeli kilka wątków czyta ci jeden deskryptor plików to musiałbyś się bawić
w zmienne w stylu "thread_id_in_read", i na tej podstawie słać sygnały - ale
to już zabawa w synchronizację.

read(2) nie jest przystosowany do wielowątkowego obsługiwania, lepiej byłoby
aby 1 wątek robił read(2) na fd, jakoś to wstępnie procesował, po czym
wrzucał na jakąś synchronizowaną kolejkę, która może już być odczytywana
przez wiele wątków.

t1:
while (1) {
struct data_frame frame;
read_until_full_frame_is_received(&frame);
queue_push(&frame);
}

t2, t3, t4...:
while (1) {
struct data_frame frame;
queue_pop(&frame);
process_frame(&frame);
}

W takim przypadku to nawet nie powinno być potrzeby bawić się w EINTR. Nie
znam konkretnego użycia więc też ciężko się odnieść do tego trochę.

>
> > Jak kod ma być przenośny między unixami, należy
> > pamiętać by wyłączyć SA_RESTART na systemach z rodziny BSD przy
> > pomocy siginterrupt(3).
>
> No i tu właśnie jest problem. To ogromna apliakcja. Z powodu kilku ::read
> mam manipulować krytyczm, globlanym stanem aplikacji? Brzmi jak 1 z
> kolokwium z inżynierii programowania.

Jak 1 z kolokwium to brzmi "To ogromna aplikacja" ;-) Dodatkowo, zmierzyłeś
że problem z wydajnością jest spowodowany przez select/poll? Jak masz tam
raptem kilka deskryptorów, to ciężko mi uwierzyć żeby to miało taki narzut
na wydajność i problem jest zapewne gdzie indziej. To, albo optymalizujesz
program na siłę.

Jak bardzo chcesz mieć nieblokujący read(2) oraz nie używać polla to możesz
zawsze ustawić przy pomocy fcntl(2) ustawić flagę O_NONBLOCK, i przy każdym
read(2) gdy nie będzie danych dostaniesz zwrotkę -1 oraz errno na EAGAIN.

signature.asc

heby

unread,

Nov 5, 2020, 9:26:27 AM11/5/20

to

On 05/11/2020 13:43, michal....@bofc.pl wrote:
> Jak 1 z kolokwium to brzmi "To ogromna aplikacja" ;-)

To raczej problem z okolic "w ksiąze do programowani jest taki przykłąd
na 3 linijki i działa", a potem masz bazę kodu na ~500MB (nie
przesadzam) i zastanawiasz się jaki idiota wymyślił globalny handler
który ma obsługiwać setki równoległych i kompletnie niezależnych części
tej aplikacji.

> Dodatkowo, zmierzyłeś
> że problem z wydajnością jest spowodowany przez select/poll?

Apliakcja wykonuje miliony ::read( *foo, 4 );. Ogólnie wykonuje bardzo
dużo małych read na namedpipe, bezustannie komunikujac się z inną
apliakcją (inny proces). Przypuszczam że każdy ::read to switch
kontekstu do kernela, albo przynajmniej jakieś cieżkie operacje na
granicy kernel/user space.

> Jak masz tam
> raptem kilka deskryptorów, to ciężko mi uwierzyć żeby to miało taki narzut
> na wydajność i problem jest zapewne gdzie indziej. To, albo optymalizujesz
> program na siłę.

Nie, zostało to dokładnie rozpracowane. ::read jest znaczaco szybszy niż
::poll->::read. Nawet w syntetycznym przykładzie da się to zobaczyć.

> Jak bardzo chcesz mieć nieblokujący read(2) oraz nie używać polla to możesz
> zawsze ustawić przy pomocy fcntl(2) ustawić flagę O_NONBLOCK, i przy każdym
> read(2) gdy nie będzie danych dostaniesz zwrotkę -1 oraz errno na EAGAIN.

Jesli teraz zawolam ::read ponownie i tak w kółko to właśnie przerobiłem
komputer na grzejnik. A jak wstawie usleep... no własnie...

michal....@bofc.pl

unread,

Nov 5, 2020, 10:00:53 AM11/5/20

to

On 2020-11-05 15:26:23, heby wrote:
> On 05/11/2020 13:43, michal....@bofc.pl wrote:
> > Dodatkowo, zmierzyłeś
> > że problem z wydajnością jest spowodowany przez select/poll?
>
> Apliakcja wykonuje miliony ::read( *foo, 4 );. Ogólnie wykonuje bardzo dużo
> małych read na namedpipe, bezustannie komunikujac się z inną apliakcją (inny
> proces). Przypuszczam że każdy ::read to switch kontekstu do kernela, albo
> przynajmniej jakieś cieżkie operacje na granicy kernel/user space.

I to jest twój główny problem. Wołanie ciągle read(2) z tak małym
parametrem count rozwala ci całkowicie wydajność. Jak sam piszesz,
każdy read(2) to przejście do kernela, a to jest bardzo droga operacja,
zwłaszcza jak robisz "miliony" tego.

Moja propozycja rozwiązania jak wcześniej. Niech 1 wątek czyta ciągle
w pętli deskryptor, z dużym rozmiarem (jak 10kB), jak będzie mniej
danych niż 10kB to read(2) wyjdzie i zwróci liczbę odczytanych bajtów.
Te dane wrzucaj na kolejkę synchronizowaną i niech sobie reszta wątków
czyta to nawet i po 1 bajcie. Wołanie funkcji jest kilka rzędów wielkości
szybsze niż wołanie syscalla.

signature.asc

heby

unread,

Nov 5, 2020, 1:16:46 PM11/5/20

to

On 05/11/2020 16:01, michal....@bofc.pl wrote:
> Moja propozycja rozwiązania jak wcześniej. Niech 1 wątek czyta ciągle
> w pętli deskryptor

Wtedy tracę coś co nazywa się synchronizacją.

Konkretnie: mam przeczytać 3 bajty, stwierdzić że to oznacza "skasuj
plik", podpowiedzeć "ack", druga strona utworzy nowy itd itp.

Bezustannie są wymieniane polecenia pomiędzy dwoma procesami "zrób to i
to","gotowe","zrób coś innego","a ty zrób to" itd.

Mam pewna przestrzeń na grupowanie tych read/write, ale to mi nijak nie
pomaga w poprawnym, przerywalnym read, bo problem z ::poll dalej będzie
istniał, tyle że zredukuje jego siłę spowolnienia.

Na razie wydaje mi się że nie da się tego zrobić dobrze, po prostu
konepcja posixa z sygnałami jest gówno warta do większych zastosowań,
::pool+::read są drogie, innych rozwiązań nie ma.

> Wołanie funkcji jest kilka rzędów wielkości
> szybsze niż wołanie syscalla.

Wszystko jest oczywiste, niesety messages latające po rurach mają na
wyższym proziomie abstrakcji znaczenie synchronizujące i nie da się tego
tak trywialnie z mienić.