w sumie to nigdy sie nad tym nawet nie zastanawialem
ani tez nic nie czytalem i nie wiem -

czy asynchroniczne io są w uzyciu? czy moze jest jakas
wersja pod winde? wydawaloby sie ze angazowanie procka
albo nawet nie jst potrzebne albo na pewno nie jest
potrzebne jako pelny blokujacy proces (skoro io ma
predkosc znacznie mniejsza niz przetwazanie procka
(choc niby teraz nawet io sa czybkie, no ale nie
az tak)

jak wyglada sprawa z takim asynchronicznym api do io?
czy ktos tego uzywa czy jednak 99% swiata uzywa zwyklego
synchronicznego inputu jak fread() (ktory jak rozumiem
po prostu wiesza i marnuje procka) ?





--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

alter amonu <f...@N...gazeta.pl> napisał(a):
> w sumie to nigdy sie nad tym nawet nie zastanawialem
> ani tez nic nie czytalem i nie wiem -
> czy asynchroniczne io są w uzyciu? czy moze jest jakas
> wersja pod winde?

DWORD written;
OVERLAPPED osReader = {0};
osReader.hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
WriteFile(hCommPort, buf, 1, &written, &osReader);
WaitForSingleObject(osReader.hEvent, 100);

> wydawaloby sie ze angazowanie procka
> albo nawet nie jst potrzebne albo na pewno nie jest
> potrzebne jako pelny blokujacy proces (skoro io ma
> predkosc znacznie mniejsza niz przetwazanie procka
> (choc niby teraz nawet io sa czybkie, no ale nie
> az tak)
> jak wyglada sprawa z takim asynchronicznym api do io?
> czy ktos tego uzywa czy jednak 99% swiata uzywa zwyklego
> synchronicznego inputu jak fread() (ktory jak rozumiem
> po prostu wiesza i marnuje procka) ?

I tak i tak nie ma angażowania procka. Czy programik z funkcją scanf()
zajmuje Ci 100% czasu procesora? Dzięki asynchrocznemu I/O można coś robić
podczas operacji I/O bez tworzenia wątku. Startujesz operację, robisz sobie
coś innego, zbierasz wynik operacji.
Przy blokującym I/O czas procesora się marnuje w ten sposób, że wątek który
uruchomił tę operację nic nie robi. Ale to nie znaczy, że procesor nie jest
dostępny dla innych wątków/procesów. Zastanawiałeś się jak to jest, że
aplikacje kręcące się w windowsowej pętli komunikatów nie zajmują 100%
procka? Podobnie jak przy scanfie scheduler w jądrze dba o to, żeby
udostępniać procesor innym aplikacjom podczas operacji I/O.

--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 0 days, 5 hours, 9 minutes and 6 seconds

do góry

Grzegorz Niemirowski <g...@p...onet.pl> napisał(a):

> alter amonu <f...@N...gazeta.pl> napisał(a):
> > w sumie to nigdy sie nad tym nawet nie zastanawialem
> > ani tez nic nie czytalem i nie wiem -
> > czy asynchroniczne io są w uzyciu? czy moze jest jakas
> > wersja pod winde?
>
> DWORD written;
> OVERLAPPED osReader = {0};
> osReader.hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
> WriteFile(hCommPort, buf, 1, &written, &osReader);
> WaitForSingleObject(osReader.hEvent, 100);
>
> > wydawaloby sie ze angazowanie procka
> > albo nawet nie jst potrzebne albo na pewno nie jest
> > potrzebne jako pelny blokujacy proces (skoro io ma
> > predkosc znacznie mniejsza niz przetwazanie procka
> > (choc niby teraz nawet io sa czybkie, no ale nie
> > az tak)
> > jak wyglada sprawa z takim asynchronicznym api do io?
> > czy ktos tego uzywa czy jednak 99% swiata uzywa zwyklego
> > synchronicznego inputu jak fread() (ktory jak rozumiem
> > po prostu wiesza i marnuje procka) ?
>
> I tak i tak nie ma angażowania procka. Czy programik z funkcją scanf()
> zajmuje Ci 100% czasu procesora? Dzięki asynchrocznemu I/O można coś robić
> podczas operacji I/O bez tworzenia wątku. Startujesz operację, robisz sobie
> coś innego, zbierasz wynik operacji.
> Przy blokującym I/O czas procesora się marnuje w ten sposób, że wątek który
> uruchomił tę operację nic nie robi. Ale to nie znaczy, że procesor nie jest
> dostępny dla innych wątków/procesów. Zastanawiałeś się jak to jest, że
> aplikacje kręcące się w windowsowej pętli komunikatów nie zajmują 100%
> procka? Podobnie jak przy scanfie scheduler w jądrze dba o to, żeby
> udostępniać procesor innym aplikacjom podczas operacji I/O.
>
ok, no to sie mw wyjasnilo, tnx za odp

ja poki co pisze aplikacje jednowatkowe (ale charakteryzujace sie
zapotrzebowaniem na czas procka), podobnie fakt ze jak ja wczytuje
dane z pliku, to aplikacje w tle moga przejac procka nie specjalnie
mi sie bezposrednio przydaje - sprowadza sie to wiec w moich prztpadkach
do przestoju procka, poki co mi to specjalnie nie przeszkadzalo
(bo i tak nie lubie uzywac duzo dysku, pozatym wole prostote niz
trdnosci), ale warto zwrocic na to uwage, pewnie i tak sporo
aplikacji uzywa blokujacego io (np programy do rysowania,
wiekszosc progsow chyba zalicza zwis az sie zapisze albo
wczyta etc)





--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

alter amonu <f...@n...gazeta.pl> wrote:

> czy asynchroniczne io są w uzyciu?

W większości programów sieciowych do komunikacji z siecią używa się
asynchronicznego IO. Zwis programu podczas czekania na odpowiedź
serwera wydaje się dosyć słabym pomysłem, nie sądzisz?

--
Gof

do góry

Dnia Wed, 6 Jun 2012 05:39:23 +0000 (UTC), Adam Wysocki napisał(a):

>> czy asynchroniczne io są w uzyciu?
>
> W większości programów sieciowych do komunikacji z siecią używa się
> asynchronicznego IO. Zwis programu podczas czekania na odpowiedź
> serwera wydaje się dosyć słabym pomysłem, nie sądzisz?

Imho raczej uzywa sie watkow, a tam moze byc polaczenie blokujace i nie
przeszkadza w normalnej pracy aplikacji.

--
pozdro
R.e.m.e.K

do góry

R.e.m.e.K wrote:

> Dnia Wed, 6 Jun 2012 05:39:23 +0000 (UTC), Adam Wysocki napisał(a):
>
>>> czy asynchroniczne io są w uzyciu?
>>
>> W większości programów sieciowych do komunikacji z siecią używa się
>> asynchronicznego IO. Zwis programu podczas czekania na odpowiedź
>> serwera wydaje się dosyć słabym pomysłem, nie sądzisz?
>
> Imho raczej uzywa sie watkow, a tam moze byc polaczenie blokujace i nie
> przeszkadza w normalnej pracy aplikacji.

Rozwiązania na wątkach zwykle są znacznie gorsze: zużywają więcej zasobów,
oraz wyraźnie komplikują program.

do góry

Dnia Wed, 06 Jun 2012 19:44:46 +0200, Wojciech Jaczewski napisał(a):

>>> W większości programów sieciowych do komunikacji z siecią używa się
>>> asynchronicznego IO. Zwis programu podczas czekania na odpowiedź
>>> serwera wydaje się dosyć słabym pomysłem, nie sądzisz?
>>
>> Imho raczej uzywa sie watkow, a tam moze byc polaczenie blokujace i nie
>> przeszkadza w normalnej pracy aplikacji.
>
> Rozwiązania na wątkach zwykle są znacznie gorsze: zużywają więcej zasobów,
> oraz wyraźnie komplikują program.

W dobie procesorow wielordzeniowych raczej wykorzystuja te zasoby lepiej. Co
do komplikacji to juz chyba sporo zalezy od przypadku i bibliotek uzywanych
do obslugi watkow. Choc oczywiscie trzeba wiedziec co sie robi i posiadanie
tej wiedzy mozna rowniez uznac za komplikacje ;-)

--
pozdro
R.e.m.e.K

do góry

R.e.m.e.K wrote:

> W dobie procesorow wielordzeniowych raczej wykorzystuja te zasoby lepiej.

Wiele rdzeni, ale połączenie obsługiwane przez jedną sieciówkę. Po co więc
dzielić coś na wątki, by potem pomagać sobie różnymi mechanizmami, aby
wykonywało się sekwencyjnie...

> Co do komplikacji to juz chyba sporo zalezy od przypadku i bibliotek
> uzywanych do obslugi watkow.

Program wielowątkowy jest podatny na pewną grupę problemów, które nie mają
możliwości wystąpić w programie jednowątkowym. I to niezależnie od użytych
bibliotek.

> Choc oczywiscie trzeba wiedziec co sie robi i
> posiadanie tej wiedzy mozna rowniez uznac za komplikacje ;-)

Z doświadczenia widzę, że częściej ludzie nie wiedzą jak się używa operacji
asynchronicznych, niż jak się używa wątków (nie wnikając w temat, czy
używają ich "dobrze", bo ciężko zdefiniować, co to "dobrze" może znaczyć).

do góry

R.e.m.e.K <g...@d...null> napisał(a):

> Dnia Wed, 06 Jun 2012 19:44:46 +0200, Wojciech Jaczewski napisał(a):
>
> >>> W większości programów sieciowych do komunikacji z siecią używa się
> >>> asynchronicznego IO. Zwis programu podczas czekania na odpowiedĹş
> >>> serwera wydaje się dosyć słabym pomysłem, nie sądzisz?
> >>
> >> Imho raczej uzywa sie watkow, a tam moze byc polaczenie blokujace i nie
> >> przeszkadza w normalnej pracy aplikacji.
> >
> > Rozwiązania na wątkach zwykle są znacznie gorsze: zużywają więcej zasob
> Ăłw,
> > oraz wyraźnie komplikują program.
>
> W dobie procesorow wielordzeniowych raczej wykorzystuja te zasoby lepiej. Co
> do komplikacji to juz chyba sporo zalezy od przypadku i bibliotek uzywanych
> do obslugi watkow. Choc oczywiscie trzeba wiedziec co sie robi i posiadanie
> tej wiedzy mozna rowniez uznac za komplikacje ;-)
>
tego typu wielowatkowosc/asynchronicznosc jak tu (czyli zapusc
asynchronicznie wczytywanie czy zapisywanie powiadom na konic)
latwo daloby sie wpisac w model eventowy, tj powiadomic eventem
na koncu (choc cholera wie czy byloby to specjalnie wygodne,
byloby to jednak dosyc/bardzo proste dla kogos kto umie uzywac
eventow w winapi

wogole ta windowsowa evenciarka i wielowatkowosc zachodza
na siebie w wielu aspektach (mimo ze to niby co innego)






--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

alter amonu <f...@g...pl> wrote:

> choc cholera wie czy byloby to specjalnie wygodne,

Na pewno wywołanie funkcji i poczekanie, aż ona wróci, jest wygodniejsze niż
wywołanie funkcji i później obsłużenie eventa. Pytanie co chcesz osiągnąć.

> byloby to jednak dosyc/bardzo proste dla kogos kto umie uzywac eventow
> w winapi

Programowanie nie kończy się na winapi.

> wogole ta windowsowa evenciarka i wielowatkowosc zachodza
> na siebie w wielu aspektach (mimo ze to niby co innego)

W jakim sensie?

--
Gof

do góry