Autor: Grzegorz Szyszlo (znik_at_avalon.wbc.lublin.pl)
Data: Mon 10 Jul 2000 - 18:43:48 MET DST
Tomasz Szczesniak wrote:
> To jedno, a po drugie są tworzone jakieś (w zalezności od przyjętego modelu
> zarządzania pamięcię) struktury danych jądra dla teog procesu. Zreszta jak to
> jes w OS/2:
w OS/2 jest przyjety scisle okreslony model zarzadzania pamiecia.
> Czy każde odwołanie do *alloc() może tworzyć odrębny segment danych,
> czli innymi słowy, jeden program może mieć jednocześćnie kilka segmentów danych,
> cz wszystkie zaalokowane obszary są w jednym segmencie?
to zalezy od programu. program moze miec kazdy, nawet najmniejszy
segment
danych przydzielony od systemu, i to w praktycznie dowolnej ilosci
segmentow.
moze tez przydzielic sobie jeden wielki segment, i w nim na wlasna reke
allokowac sobie obszary. moze takich wielkich segmentow przydzielic
sobie kilka, moze tez uzywac wszystkich sposobow naraz. jesli chodzi o
GNU C, takze w odniesieniu do OS/2 jest to dokladnie ukryte przed
programista w funkcji alloc() lub obiektowo w new() .
> Ta druga metoda jest
> prostsza, deskryptor procesu ma tylko trzy wejścia (kod, dane i stos), ale
> bardziej pracochłonna w zarządzaniu pamięcią (koniecznośc kopiowania czasami
> duzych ilości danych przy alokacji pamięci), co prawda przy stronnicowaniu już
> tak kiepsko nie jest. A pierwszym pzypadku dużo łatwiej zarządzac pamięcią, ale
> struktury daych dla procesu maja zmienną długoąć (i są większe).
w kazdy przypadku trzeba jakos zadbac o rozpoznanie roznych struktur
danych.
generalnie, w GNU C (i wielu innych kompilatorach) jest zdefiniowana
pewna zmienna, ktora okresla minimalna wielkosc bloku, ktory jest
pobierany
w jednym kawalku od systemu. jesli przydzielany blok w alloc() jest
wiekszy
rowny tej wartosci, wtedy jest to jedno proste pobranie. jesli zas
wielkosc jest mniejsza, jest pobierany wiekszy, z gory okreslonej
wielkosci
blok pamieci. takim blokiem program zarzadza wlasnymi metodami, ktore
sa wbudowane w biblioteke w ktorej jest zawarta funkcja alloc() .
w kazdym razie takie kombinowane rozwiazanie niewiele zwieksza wielkosc
kodu, a jednoczesnie nie dopuszcza do pobierania od systemu drobnicy
blokow pamieci. jesli chodzi o swapowanie, to os/2 podobnie jak linux
potrafi wyswapowac fragment bloku, a w ramie pozostawic czesc wlasnie
uzywana. winda ma z tym problem.
wiecej pisal nie bede bo napisalem juz wszystko. gdyby co, odsylam
do helpa, takze linuxowego.
> >> Czy lepiej jest zarezerowac pewien ciagly obszar pamieci z gory i
> >> ew. kiedy stanie sie za maly zwiekszyc go realloc()?
> GS> To jest oplacalne ale tylko wtedy, kiedy rezerwujesz obszary dla
> GS> jednolitego
> GS> rodzaju danych o jednakowej wielkosci. inaczej koszty zwiazane z
> GS> algorytmem
> GS> zarzadzania moga przewyzszac te, ktore sa standardowo (z reguly)
> GS> wbudowane
> GS> w *alloc() .
>
> I o to mi m.in. chodzło, czy alloc() też zarządza pamięcią, czy jest tylko
> prostym odwołaniem do odpowiedniej funkcji systemu.
tez zarzadza. sa utworzone struktury zmiennych statycznych, ktore
pamietaja co i gdzie zostalo zarezerwowane.
> >> (lista ma zmienna dlugosc, moze
> >> miec 100 elementow, ale i 100 tysiecy)
> GS> to niewazne. wazne by elementy byly jednakowej wielkosci.
>
> Nie są. Gdyby były byłoby prościej - zadeklarowałbym tablicę. A tak muszę miec
> tablicę wskaxników na elementy (u mnie kurat jest lista, bo wystarczy dostęp
> sekwenycjny)
wiec najnormalniej w swiecie uzywaj alloc(), chociaz ja polecam new()
bo jest latwiejsze w obsludze.
> >> I drugie pytanie: Czy jest mozliwosc trzymania jakiegos fragmentu
> >> pamieci (dane i kod) zawsze w pamiec fizycznej? (innymi slowy, zeby
> >> system go nigdy nie wyswapowal?)
> GS> jest taka mozliwosci, ale nie wiem na czym to polega.
>
> Nie do zrealizowania w normlanym programie?
do zrealizowania. pytanie po co?
-- /===================================\ oOOo (C) Publikacja tego | http://avalon.wbc.lublin.pl/~znik/ \===\__/==\ artykulu lub jego | Grzegorz Szyszlo mailto:znik_at_wbc.lublin.pl | fragmentow w Gaz.Wyb. \==============================================/ surowo wzbroniona.
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 15:28:04 MET DST