Informatyka UJ forum

pawell

dokladnie.. :)

Spectro

@Stasiu:
Chyba trochę się zagalopowałeś.

Co prawda w Silberze jednak pamięć jest rozważana od góry (sprawdziłem), ale... Podrozdział 3.5.2 -> patrz rysunki. Warstwy są rozważane od dołu. Chodzi o zupełnie inne warstwy, ale jednak. Tobie może się wydawać, że pierwsze warstwy to warstwy od góry, mnie że warstwy od dołu. I obaj mamy rację, bo pytanie nie było jednoznaczne.

Coś czuję, że przez takie właśnie rzeczy miałem tak kiepski wynik punktowy... :?

Rogal

@Stasiu: Heh, mam nadzieję, że jak kiedyś nie będziesz rozumiał czegoś z innego przedmiotu to ktoś nie powie Ci, że to jest banalne i żebyś nie robił z siebie kompletnego idioty :?

Stasiu

hehehehe. Dobra nie zaczynajmy znowu, przepraszam za swoje słowa. Ale nie mówiłem, że to było banalne, tylko że z rysunku w książce wynika, że pierwsza warstwa, to ta na górze.

Piotr Kalita

Rozumiem Panstwa rozgoryczenie ale uwazam ze niektorzy z Panstwa zareagowali zbyt emocjonalnie a takie reakcje emocjonalne maja to do siebie ze z reguly wychodza na niekorzysc reagujacego.

Nie wiem kto jeszcze poza mna tu w instytucie czyta to forum ale zapewne takie osoby sa. Sadze ze jesli ktos zainteresowany to bedzie czytal to albo zignoruje to albo przemowia do niego raczej wywazone posty Rogala czy Spectra niz te bardziej agresywne (tym bardziej ze Shell ktory jest autorem tych agresywnych postow iles tam razy bil sie za to w piersi).

Co do pytania o hierarchie pamieci to moim zdaniem bardziej intuicyjnym jest widzac pytanie 'trzy pierwsze' napisac trzy pierwsze od gory.

Co do RPC to klasyczne RPC jest synchroniczne (bo z reguly zwraca jakies wartosci) i jesli mamy do czynienia z asynchronicznym RPC to explicite pisze sie 'asynchroniczne RPC' (w corbie z ktorej przyklad robilem na cwiczeniach jest do tego jakies slowo kluczowe).

Poza tym proponuje calkiem zamknac dlasza dyskusje.

pawell

Rogal

+1

admini zadziałajcie w końcu :D

hansu

Ja osobiscie uwazam ze jezeli ktos chce sie jeszcze w tym temacie wypowiedziec to z mojej strony nie w porzadku byloby zamykac... Jestesmy dorosli i kazdy odpowiada za swoje slowa wiec... nie mam zamiaru byc dobrym tata i odbierac ludziom glosu dla ich wlasnego dobra...

Piotr Kalita

Nie chodzi mi o fizyczne zamykanie tylko raczej o to co pisze Kap00ch. Nie uwazam ze nalezy ludziom ograniczac wolnosc slowa tylko raczej zeby sami rozumieli ze nie jest zawsze wskazane pelne jej wykorzystywane.

Lupus

Piotr Kalita

No fakt. Odpowiadajac ze nie mozna uzyc rejonu krytycznego mialem w domysle na uwadze rejon bez dozoru czyli po prostu operacje

region s do
{
...
}

Wtedy taki rejon bedzie po prostu mutexem i filozofowie korzystajacy z niego zakleszcza sie a problemu producenta i konsumenta nie da sie rozwiazac.

Natomiast jesli wprowadzimy dozor czyli operacje

region s when warunek do
{
..
}

to wtedy oczywiscie mozna rozwiazac nim wszystkie problemy programowania wspolbieznego bo bedzie to konstrukcja rownowazna semaforowi.

(uwazam ze region i rejon to to samo po prostu angielskie slowo region tlumaczy sie czasem na polskie rejon)

cedric

A ja powiem tak moim zdaniem przynajmniej 3 pytania zasługują na anulowanie, przede wszystkim to o rpc, dla chętnych polecam zapoznanie się z [link widoczny dla zalogowanych]

ponadto pytanie o warunkower rejony krytyczne, bo nie było powiedziane czy z dozorami czy bez, oraz pytanie dotyczące czytelników i pisarzy - było tam napisane o transakcyjnym systemie bankowym, można to było zrozumieć na 2 sposoby to jest jako system transakcji bankowych, przy czym ten wystarczyłoby zrobić zwykłymi semaforami, albo system transakcyjny, którego ciężko by było zrobić w sytuacji banku, w której i czytelnicy i pisarze muszą być ograniczani było by zrobić.

Piotr Kalita

Zgadzam sie ze mozna tu dyskutowac (zwlaszcza jesli chodzi o rejon).

Co do RPC to tam na dole strony jest obrazek w ktorym synchroniczne rpc jest nazwane standardowym an asynchronicznosc zostala wymieniona dopiero w punkcie 'mozliwe modyfikacje rpc'.

Poza tym pytanie bylo sformulaowane 'czy rpc umozliwia synchronizacje procesow?' a synchroniczne rpc umozliwia wiec jakis jego rodzaj umozliwia wiec rpc umozliwia (ale to juz jest filozofia a nie informatyka).

W kwestii czytelnikow i pisarzy to wszystkie systemy bazodanowe sa oparte na transakcjach a trudno sobie wyobrazic bank bez bazy danych poza tym wydaje sie jasnym ze chodzilo tu o informatyczne znaczenie slowa 'transakcyjny'.

cedric

ależ oczywiscie że struktury transakcji bankowych nie da się zaimplementować za pomocą czytelników i pisarzy!!!!!
przecież bank nie może dopuszczać multiple-read!!!
Gdyby dopuszczał to na podstawie zgromadzonych aktywów na koncie byłby w stanie udzielić wyższego kredytu, a w tym samym czasie ktoś mógłby się pozbywać tych pieniędzy z konta!!!!!
transakcja w banku to nie tylko wykonanie dyspozycji!!
Zresztą nawet Dr Kotulski pokazywał przykład ArtB na wykładzie jako przykłąd, że jeżeli jest dozwolony multiple read to mogą się chece podziać (tj można wyłudzać z banku mnóstwo kasiory)

cedric

co do RPC to nazwa RPC jest ogólną nazwą na Remote Procedure Call (czyli zdalne wywołanie procedur), a asynchroniczność czy synchroniczność, to jest cecha implementacji RPC,
(o implementacji w ogóle nie było mowy na wykładzie, i słusznie bo to temat na SK,)
a nie samego RPC. Pan mówił o tym że w corbie jest zaznaczenie czy chcemy implementować RPC w taki a nie inny sposób.
I dobrze bo jeśli potrzebujemy coś zaimplementować o musimy wiedzieć jak, ale na Boga!!! przecież to że w C++ nazwa tablicy jest jej adresem to nie znaczy że w każdym języku programowania nazwa tablicy jest wskaźnikiem na pierwszy element@!!

Na tej zasadzie możemy równie dobrze powiedzieć że wszytkie słonie są różowe, bo znalazłem jednego w indiach i go pomalowałem na różowo!!

Crow

@cedric: A nie multiple-write? Tam raczej chodzilo o to ze w czasie gdy ktos zapisuje (lub trwa transakcja zapisywania) to niemozna czytac. Ale by byly chece jakby stan konta w banku mogl na raz czytac tylko jeden klient/kasjer/program.

Co do RPC - Remote Procedure CALL. Czy zatem nie jest naturalnym ze wywolanie musi byc synchroniczne... a wszelkie asynchroniczne implementacje sa sztuczne? Asynchroniczne RPC powinno miec raczej nazwe: RPE (Remote Procedure Execution) :P To tak jakby rozkaz CALL w assemblerze byl asynchroniczny - mozna... ale po co?

cedric

tak ale jak masz multiple read to na podstawie nieaktualnych danych można ci przyznać wyższy kredyt!! chociażby, albo możesz w 10 oddziałach banku na raz zaciągnąć kredyt bo w żadnym nie zostało to jeszcze zaklepane ( pod warunkiem że masz braci syjamskich) Schemat takiego szwindlu jest taki sam jak w sprawie ArtB tyle że tam nie dość że był dozwolony i multi-re i multi-wr,

Piotr Kalita

Nie rozumiem do konca - przeciez jak mamy pisarza czyli tego kto usuwa pieniadze z konta to czytelnik czyli ten ktory udziela kredytu nie moze wejsc, bo z pisarzem nie moze dzialac zaden czytelnik.

Poza tym z tym przydzielaniem kredytu to transakcja powinna trwac dopoki nie bedzie wszystko zaklepane.

Ale nawet jesli niektore operacje ktore z pozoru wygladaja tylko na czytanie musialyby byc tak naprawde pisaniami, to sa tez niegrozni czytelnicy ktorych czytania mozna by uwspolbieznic: np sprawdzania stanu konta z bankomatow.

Crow

Pan Doktor mnie ubiegl z odpowiedzia. :)

(Co do Art-B to chodzilo raczej o roznice w czasie ksiegowania wplywow w bankach - tzw. oscylator)

cedric

co do RPC.
Nie nie jest naturalnym
np chcesz znaleźć drogę do jakiegoś serwera. Standardowy algorytm jest losowy wybierasz losowo serwer dns jaki znasz a stamtąd losowo kolejne.
Gdybyś oczekiwał na response od każdego serwera to mbyłbyś mega w d...ie :D bo,
a) chodzi o to żeby znaleźć tę najkrótszą (prawie) drogę do serwera
b) jak jakiś serwer jest zamknięty to oczekując na powrót któregoś z sygnałów poczekasz sobie do nieskończoności
c) ogólnie rzecz biorać naturalne dla człowieka jest nie czekać na rezultaty swojej pracy tylko pracować dalej

Crow

eee... wyszukiwanie DNS nie jest RPC... Podkreslam: Procedure Call jest odpowiednikiem rozkazu CALL w procesorach... tyle ze na innej maszynie za posrednictwem sieci... A rozkazu CALL nie wykonuje sie asynchronicznie na jednym procesorze. Wyszukiwanie ma zupelnie inny mechanizm! Rownie dobrze mozna by powiedziec ze to ze slonie nie maja skrzydel jest nienaturalne - przeciez fajnie jest sobie polatac!

cedric

@Kalita
T0 ne jest do końca tak
robimy tak
1) chcemy udzielić kredytu, do tego sczytujemy info o stanie konta
2) czytamy ilość kasiory na koncie
3) wybieramy kasiorę z konta
4) udzielenie kredytu (wyższego niż jest teraz możliwy

drugi schemat

w którym jaśniejsze jest że nie może parę procesów czytać.

1a) czytamy ile kasy na koncie
1b) czytamy ile kasy na koncie
1c) czytamy ile kasy na koncie
1d) czytamy ile kasy na koncie
1e) czytamy ile kasy na koncie
1f) czytamy ile kasy na koncie
2f) dostajemy kredyt
2e) dostajemy kredyt
2d) dostajemy kredyt
2b) dostajemy kredyt
2c) dostajemy kredyt
2a) dostajemy kredyt

cedric

@CRow no ok wiem że nie jest ale to mniej więcej o to chodzi, po co zawsze chcesz wiedzieć że procedura się wykonała
w większości wypadków jesteś w stanie z łatwością pracować bez tego. Albo oczekujesz na większą ilość danych.

Po co wysyłać 1 informację jak możesz wysłać n informacji i do tego jakoś sprytnie spakowanych

Crow

eee... ale akurat przydzial kredytu nieobciaza stanu konta - wszystko jest ok. Biorac kredyt nie tracisz srodkow!

Nie bede sie powtarzal - RPC jest odpowiednikiem rozkazu CALL - odsylam do stosownej dokumentacji