Informatyka UJ forum

cedric

ale bierzesz 10 kredytów, gdy tak na prawdę bank pozwala wziąć tylko 1!!!
w ten sposób mając dowolny środki finansowe byłbyś w stanie brać dowolny kredyt

No chyba mi nie powiesz że jak pójdziesz do banku i poprosisz o 1M$ kredytu to ci go dają od tak od reki jak teraz pójdziesz choćby do eurobanku

@CROW Przykład banku to jest do czytelników i pisarzy a nie do RPC

Piotr Kalita

Rozumiem.

W pierwszym schemacie jednak bym sie upieral ze czytelnicy/pisarze zadzialaja, bo bedzie to tak:

zamykamy readlock
punkt 1 chcemy udzielic kredytu
punkt 2 czytamy ilosc kasiory

punkt 3 chcemy wyplacic ale system nam nie pozwala bo jestesmy pisarzem a readlock jest zamkniwty

W drugim schemacie to ma Pan racje. Ale w zasadzie 'dostajemy kredyt' jest tu pisaniem bo modyfikuje stan konta - tzn zapisuje na nim ze jest kredyt, wiec w ogole bardziej adekwatne byloby zamkniecie writelocku juz przed sprawdzeniem stanu konta w procesie ktory chce wziac kredyt.

Crow

(@Cedric: no dlatego tam byl odstep...)

cedric

nie no dostawanie kredytu to jest tylko decyzja, decyzja jest podejmowana na podstawie czytania.

System bankowy powinien tak działać, żeby każda kolejna prośba o kredyt jeżeli mamy już jeden udzielony była odmowna co implikuje że musimy zablokować czytanie w trakcie decydowania o kredycie
potencjalnie przyznanie kredytu nie zminienia wielkości konta, nie pisze po koncie. Jedyne na co pozwala to na zadłużenia się w późniejszym czasie.

Znaczy tak to jest realizowane w bankach, przynajmniej tak mi jest to wiadome

cedric

@ CROW

cytując z MIMUW

Asynchroniczne RPC - są możliwe trzy optymalizacje:

* kiedy nie jest wymagana odpowiedź, klient może wywołać zdalną procedurę i pójść dalej nie czekając aż serwer zakończy jej wykonanie; przykłady: przesłanie pieniędzy z jednego rachunku na drugi, przetwarzanie wsadowe;

* kiedy nie jest wymagana odpowiedź, można zebrać kilka żądań klienta i wysłać razem;
* nawet jeśli jest wymagana odpowiedź, to klient może wywołać zdalną procedurę nie czekając na odpowiedź i odebrać tę odpowiedź później; przykłady: klient przekazuje serwerowi listę nazw komputerów do odszukania w sieci, serwer po skompletowaniu listy przekazuje ją klientowi.

Crow

No jak dla mnie to wyglada tak:

Czytajac stan konta dostajesz informacje o maksymalnej kwocie kredytu ktory mozesz otrzymac. Jesli chcesz kredyt to rozpoczynasz pisanie... zglaszasz chec uzyskania kredytu podajac jego kwote... bank przyjmuje badz odrzuca (jesli podales wieksza kwote niz mozesz - czyli defacto, np. tuz przed tym wyplaciles srodki z konta...). Pisarze tez moga czytac!

-----------------

Dobrze ze napisales optymalizacje... oszczedzi mi to komentarza. Skoro cos jest optymalizacja to nie jest standardowe - mam racje?

Piotr Kalita

@cedric:

jesli chodzi natomiast o RPC to jest ono w praktyce stosowane do zdalnego udostepniania uslug ktore sa mozliwe do wykonania lokalnie na jakims serwerze i tu bardziej naturalne jest czekanie.

na przyklad jesli chcemy wykonac jakies obliczenie to czekamy na wynik
jesli chcemy na serwer wyslac plik (lub sciagnac) to czekamy az on sie wysle

jesli rpc zmienia jakos stan serwera to mamy gwarancje ze po zakonczeniu procedury stan bedzie aktualny czyli jesli wykonamy dwa razy zdalna procedure zmieniajaca stan to serwer dokona tych zmian w takiej kolejnosci w jakiej zada tego wywolujacy

Crow

RPC [link widoczny dla zalogowanych]

cedric

No ale teraz to już nie są czytelnicy i pisarze

w tym problemi przynajmniej tak to było i na wykładzie i na ćwiczeniach u Dr Moczurada
że pisarze tylko piszą a czytelnicy tylko czytają zatem nie korzystasz już z problemu czytelników i pisarzy, ale z problemu czetlinkopisarzy i czytelników

wracając co napisałem na początku RPC jest ogólną nazwą na zdalne wywołanie procedur.
Jak to jest robione to inna kwestia. Mnie chodzi tylko o to, że synchroniczne RPC daja takie same możliwości jak Asynchroniczne.
Poza tym jak będziesz się bawił w programowanie jakiegoś systemu rozproszonego z RPC, to pierwszym krokiem po jaki wykonasz to skorzystanie z RPC asynchronicznego żeby zwiększyć wydajność. Tak się składa póki co że zazwyczaj że zazwyczaj transport siecią jest kosztowniejszy niż wykonanie czegoś na procesorze i z roku na rok ta różnica się pogłębia.

Kurcze nie wiem jak cię przekonać. ALe może choćby jak korzystasz z jakiegoś Edonkeya albo czegoś. Tam też nie wysyła ci po jednym bicie tylko całymi paczkami.
Więc nawet tam masz asynchroniczne RPC

Crow

TO NIE JEST RPC! RPC w podstawowej wersji wykonuje procedure!!!! Emacs ma wbudowany jezyk skryptowy ale nie mowimy ze jest interpreterem tylko edytorem tekstu. Wyobrazasz sobie cos takiego:

int main()
{
int temp = JakasFunkcja(2000);
cout << temp;
return 0;
}

w ktorej JakasFunkcja wykonuje sie ASYNCHRONICZNIE?! Ja jestem w stanie to zrobic tylko po paru piwach. :P

cedric

No ale mi nie chodzi o to że RPC synchroniczne jest złe.

Mi chodzi tylko i wyłącznie o to że Dr Kotulski po egzaminie stwierdził że taka odpowiedź że istnieje RPC asynchronicznie jest zła
cytuje
"no ale jak pan chce synchronizować za pomocą asynchronicznego RPC, przecież to jest sprzeczne samo w sobie"

i ja się tego czepiam.
Fakt że RPC może być i takie i takie jest dla mnie kluczowy i o to mi się rozchodzi.

Crow

Co do synchronizacji za pomoca RPC: To co tak naprawde chcemy synchronizowac? Przeciez na serwerze dziala proces serwera, a nie jakis tam inny proces. Co zsynchronizujemy? Nasz program z biblioteka z ktorej wywolujemy funkcje poprzez RPC?

Rogal

@cedric: Nie ma co się już nad tym rozwodzić, gdybyś znał Zilbera na pamięć, także na wspak i po rumuńsku, to byś zdał a tak to szykuj się do poprawki i się ciesz że mieszkasz w Krakowie.

Crow

@Rogal: to sie nazywa rzeczowy argument :D To ja tez wracam do algebry :P

cedric

@ CROW

cite : nawet jeśli jest wymagana odpowiedź, to klient może wywołać zdalną procedurę nie czekając na odpowiedź i odebrać tę odpowiedź później;

A nóż wywołanie tej procedury ("bo na przykład służy do debugu") w ogólnie nie będzie potrzebne i efektywniejsze dla rozwiązania całego problemu którego podproblemem jest zadany przez ciebie problem. Albo wynik jest na tyle krótki że nie opłaca się go wysyłać bez jakichś innych danych. Wtedy warto troszkę poczekać i wysłać z innymi danymi, a zamiast tego pozwolić systemowi wysłać w tym czasie wiadomość komu innemu

TO jest właaśnie istota RPC asynchronicznego osczędność łączy kiedy to potrzebne

cedric

@ROGAL
Jestem ciekaw czy ty też byś się tak cieszył gdybyś np miał być oblany tylko z tego powodu że myślisz na egzaminie i analziujesz jakie są pytania. Skąd miałem wiedzieć, że tak implmentujemy RPC jak to było wymagane na egzaminie, jak na wykładzie nie mówiliśmy właściwie nic o implementacji RPC, a doczytać to musiałem z innych skryptów i innych książek

Crow

[link widoczny dla zalogowanych] - polecam czesc "How RPC works".

"RPC" jest synchroniczne, "RPC Asynchroniczne" jest asynchroniczne. Sam dodajesz okreslenie asynchroniczne zeby odroznic to od normalnego RPC

Rogal

@cedric: Zabrakło mi 1 pkt. Przynajmniej tyle straciłem na pytaniu o algorytmy przydziału procka które znałem dobrze ale nie zrozumiałem pytania :? To co napisałem to była ironia wywołana tym, co pisało wcześniej wiele osób na tym forum :?

Piotr Kalita

Ale RPC nie jest wykorzystywane do tworzenia systemow czy protokolow. Jest raczej usluga systemowa wykorzystywana do tworzenia aplikacji. A tu utworzenie nowego watku ktory caly czas bedzie w stanie oczekujacym na odpowiedz serwera nie jest rzecza zbyt kosztowna.

Ponadto nie neguje rpc asynchronicznego. Istnieje RPC asynchroniczne i czasem jest bardziej optymalne niz synchroniczne. Ale istnieje tez RPC synchroniczne i ono moze byc wykorzystane do synchronizacji.

cedric

no i właśnie o to mi chodzi, skoro istnieje rpc asynchroniczne to można było napisać w tym pytaniu odpowiedź tak na pytanie czy rpc jest asynchroniczne
tak samo jak są koty białe i koty czarne, tak jest rpc asynchroniczne i sunchroniczne

bo to pytanie przerabiając na te koty brzmiało tak

czy koty są czarne?

w sumie odpowiedź na to pytanie powinna być : " tak, ale nie wszystkie"
ale odpowiedź tak i nie powinny być tak samo punktowane