Disclaimer: Dieser Thread wurde aus dem alten Forum importiert. Daher werden eventuell nicht alle Formatierungen richtig angezeigt. Der ursprüngliche Thread beginnt im zweiten Post dieses Threads.
sbrk und POSIX
ich mach daraus mal einen neuen Thread:
neuere brk/sbrk-man-pages schreiben das - und zum Teil empfehlen sie auch, dass man doch besser malloc verwenden sollte 
Normale Programmierer sollten natuerlich auf keinen Fall mit sbrk direkt arbeiten - aber was wir hier machen ist ja auch nicht normal… 
Wosch wird in der Vorlesung in Kap. 5 beim Thema Speicher auch nochmal kurz drauf eingehen:
brk und sbrk stammen aus den Anfangszeiten von UNIX, als das Speicherlayout eines Prozesses tatsaechlich so simpel war, wie wir das in der Vorl. und den Uebungen
erzaehlen. Tatsaechlich ist das alles inzwischen doch ein ganzes Ende komplizierter heute - aber um das vernuenftig zu erklaeren, braeuchten wir noch etliches an Grundlagenstoff
zum Thema Speicherverwaltung. Ein Prozess mappt sich seinen Speicher normalerweise mit mmap zusammen. Oft gibt’s auch erheblich mehr Segmente (vor allem bei dynamisch
zusammengefummelten Prozessen) als nur die drei bisher erklaerten.
Aber letztlich gibt das vereinfachte Bild trotzdem einen ganz guten Eindruck, was sich da so abspielt - und wenn man das und die noch kommenden Grundlagen zu virtuellem Speicher
mal verstanden hat, dann ist’s auch nicht mehr schwierig, z.B. ein Reference-Manual ueber das ELF-Format und das Laden von ELF-Binaries zu verstehen.
brk und sbrk gibt es nach wie vor und die Implementierung des „echten“ malloc benutzt das intern auch - insofern ist es in unserem Kontext hier absolut in Ordnung, wenn wir das
dafuer benutzen. Alles andere waere nur komplizierter und wuerde auch keinen echten zusaetzlichen Erkenntnisgewinn im Moment bringen.
da stellt sich mir die frage ob es möglich ist einem programm einen festen speicherbereich zu reservieren (unter linux versteht sich)
Also nicht mallco sondern einen block im speicher wo alle programmsegmente reinkommen und der speicherbereich darf sich nicht mit dem anderer programme überschneiden nichtmal dem des betriebsystems
der grundgedanke dahinter ist dass man dann alle nötigen systemprozesse von denen man weiss dass sie nicht mehr benötigen im speicher fest positionieren könnte. und den rest des speichers teil man dann halt den anwendungsprogramme zu
Klingt nach nem OS ;-). Weil selbiges dürfte sich darum kümmern, dass du schön den Speicher nimmst der dir zugeteilt wird. Ansonsten würden die Rechner im CIP wohl alle paar minuten abschmieren. Oder hab ich dich falsch verstanden?
@morty: ja eben das in ein os einzubauen fände ich mal ne geniale sache alle laufenden systemprozesse komplett vom anwendungsspeicher abschirmen und die größe limitieren die jeder systemprozess verwenden kann
nur jetzige betriebssysteme vermischen ja ihre daten im speicher und wenn ein prozess aufhört zu existieren dann haste auf einmal ein kleines speicherfragment hier und da das ungenutzt ist so könntest du einfach den gesamten speicherblock als frei melden sobald der prozess zu ende ist und die fragmentierung bestünde mehr oder weniger nur auf speicherblock ebene wovon jeder wohl 1-2 mb groß sein dürfte für kleinere programme
aber eine idee die ich hätte wäre zb
dass man den verfügbaren speicher für anwendungen entsprechend klassifizieren könnte,
zb.: x mb für 16 byte vektoren == 4*float und so weiter und nen extra block wo nur richtig große speicherblöcke reinkommen wenn man dann noch ne malloc hätte die entsprechend den erfordernissen den speicher allociert im
richtigen block könnte man damit die speicherfragmentierung erheblich reduzieren
aber ich denke mal sowas lässt sich nur schwer nachträglich in ein betriebssystem einbauen
unix, linux, windows und andere Mehrbenutzerbetriebssysteme machen genau das:
Jeder Prozess sieht nur seinen eigenen Speicher (seinen logischen Adressraum) -
an Speicherbereiche anderer Prozesse oder des Systems kommt er nicht ran.
Der Speicher ist in Seiten aufgeteilt (normalerweise 8kb gross) und diese Seiten kann
man bei Speichermangel einfach auf die Platte auslagern - wenn der Prozess dann wieder
zugreift holt das Betriebssystem die Seite wieder rein (und kann sie sogar an eine andere
Stelle in den Speicher einlagern ohne dass das den Prozess stoert - in seinem logischen
Speicher bleibt sie an der selben Stelle, nur die Abbildung auf den echten Speicher -
den physikalischen Speicher - aendert sich - aber auch darum kuemmert sich das
Betriebssystem). Dadurch bekommt man auch keine Fragmentierung im Speicher -
(in dem Sinn, dass ein freier Speicherbereich zu klein ist)
alle Loecher sind gleich gross (genau 8k) und der Speicher der Prozesse ist auch
in genau solche Truemmer aufgeteilt, so dass die in jedes Loch genau reinpassen
(natuerlich werden die 8k nicht immer ganz gebraucht - hat man halt etwas Verschnitt).
Nachdem’s dann auch noch egal ist, wo so ein Speicherbereich tatsaechlich hingelegt
wird, ist das natuerlich ganz praktisch.
Speicher, der nicht immer tatsaechlich auch im echten Speicher vorhanden ist, nennt man
dann virtuellen Speicher.
Oberflaechlich erzaehlen wir das am Anfang von Kap. 5 in der Vorlesung (naechsten
Donnerstag und evtl. noch am Montag drauf), Details zu virtuellem Speicher und
Seitenein-/auslagerung kommen dann in dem Vertiefungskapitel in der zweiten
Semesterhaelfte (ich schaetze mal so Ende Juni/Anfang Juli).