einige Fragen…
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.
Fragen zu Altklausuren
Guten Tag,
beim Bearbeiten der Altklausuren ist mir bei manchen Fragen nicht klar geworden, was die richtige Antwort ist. Ich hoffe, ihr könnt mir helfen.
1. April 2010, 1. e) Vermutung: 1. oder 2. Antwort richtig
-
- Antwort: Man kann (quasi-)LRU mittels Second Chance implementieren, wofür man ein Referenzbit braucht.
-
- Antwort: Es wird aber auch die Zeit seit dem letzten Zugriff als Kriterium verwendet, da die Seite ersetzt wird, deren letzter Zugriff am Längsten her ist.
2. April 2010, 1. i) Vermutung: 1. oder 2. Antwort richtig
-
- Antwort: Über den zurückgelieferten Zeiger sollte man auf die Dateiattribute zugreifen können (zumindest lesend), sonst ist die Funktion ziemlich sinnlos.
-
- Antwort: [m]readdir [/m]gibt einen Zeiger auf eine interne Struktur zurück. Wenn [m]stat [/m]mit der gleichen Schnittstelle implementiert wäre, wäre dieser Speicher wohl im Betriebssystem allokiert (wobei man sich was schlaues ausdenken müsste, dass man auf Betriebssystemspeicher zugreifen kann)
3. April 2010, 1. n) Welche Antwort ist richtig?
Meine Vermutung ist “Sperre der Interrupts”, was aber gut geeignet ist, um gemeinsame Daten zwischen einem Prozess und einer ISR zusynchronisieren.
Welche Antwortmöglichkeiten wären bei einem Monoprozessorsystem richtig?
4. April 2010, 1. o) Welche Antworten wären richtig, wenn die Frage zur “Verklemmungsvermeidung” wäre?
5. Juli 2010, 1. i) Vermutung: 1. oder 4. Antwort richtig
Kann es zu einem Programm mehrere Prozesse geben oder nur mehrere Prozessinkarnationen?
6. August 2011, 1. i) Vermutung: 1. oder 2. Antwort richtig
Für mich klingen die beiden Antworten relativ ähnlich und könnten meiner Meinung nach beide (mit mehr oder weniger Aufwand) eingesetzt werden.
7. August 2011, 1.2 b) “Bei einer Speicheranforderung muss bei Worst-Fit u.U. die gesamte Freispeicherliste durchlaufen werden.” Ja oder Nein?
Gedanke: Um den passenden Block zu finden, muss die Liste nicht durchlaufen werden, da der erste Block der Größte ist. Wenn der angeforderte Speicher genau der Größe des ersten Blocks entspricht, ist man fertig und man muss die Liste nicht durchlaufen. (-> “Nein”)
Wenn jedoch ein Rest übrig bleibt, muss dieser wieder in die Liste einsortiert werden, die dafür durchlaufen werden muss. (-> “Ja”)
8. August 2011, 3. b) Warum Datenstrukturen? Muss man etwas außer der Pagetable mit den Flags zeichnen?
9. Februar 2012, 1.2 a) “Journaling-Dateisysteme sind immun gegen defekte Plattenblöcke.” Ja oder Nein?
Gedanke: Journaling-Dateisysteme (oder Dateisysteme generell) können defekte Plattenblöcke einfach ignorieren, weshalb es ihnen nichts ausmacht, wenn einige Blöcke defekt sind. (-> “Ja”)
Aber ein Journaling-Dateisystem sorgt nicht dafür, dass defekte Plattenblöcke wieder “heil” werden und können auch nicht den Speicher von defekten Blöcken verwenden. (-> “Nein”)
10. Februar 2012, 1.2 b) “Kooperative Schedulingverfahren ermöglichen keinen wirksamen CPU-Schutz.” Was ist “wirksamer CPU-Schutz”?
11. Februar 2012, 1. g) Vermutung: 1. oder 4. Antwort richtig
-
- Antwort: Wenn man aktiv wartet, benötigt der Prozess unnötig Zeit, die beim passiven Warten sinnvoll von anderen Prozessen genutzt werden könnte.
-
- Antwort: Es reicht die Unterstützung der Hardware.
Vielen Dank im Voraus
Mackie
https://pad.stuve.fau.de/p/SP>AUD
schau mal hier da gibts lösungen zu den altklausuren 2010 bis 2014
aber weist du vllt wo man die altklausuren selber finden kann?
Ich fang mal an mit der Klausur von April 2010.
Antwort 2 ist richtig.
Second Chance ist nur eine Approximation an LRU - weniger präzise; dafür aber ungleich einfacher zu implementieren, weil man eben nur dieses eine Referenzbit pro Seite braucht.
Der Zugriff auf Betriebssystemspeicher ist der springende Punkt! Ein Anwendungsprozess darf nicht auf Kernel-Speicher zugreifen - nicht mal lesend, denn dort könnten z. B. kryptografische Schlüssel liegen oder Netzwerkpakete mit privatem Inhalt, die für einen Prozess eines anderen Nutzers gedacht sind.
Aus diesem Grund sind die Adressräume von Anwendungsprogramm und Kernel logisch getrennt. Der Kernel darf auf den Speicher der Anwendung zugreifen, aber nicht umgekehrt. Bei jedem Wechsel zwischen Anwendung und Kern muss ein Adressraumwechsel stattfinden. Eine logische Adresse, die der Kernel verwendet, verweist im Anwendungsadressraum auf eine völlig andere physikalische Adresse → völlig zufällige Ergebnisse, wenn er versuchen sollte auf diese Adresse zuzugreifen. Oder die Adresse ist im logischen Adressraum der Anwendung überhaupt nicht gültig, dann kommt es zu einem Segfault.
Richtig wäre also Antwort 4.
Richtig. Wenn du auf einer CPU die Interrupts ausschaltest, kannst du zwar selbst nicht mehr verdrängt werden. Das hindert aber einen anderen Faden nicht daran, auf einer anderen CPU ausgeführt zu werden und von dort aus auf dieselben Daten zuzugreifen.
Auf einem Monoprozessorsystem wären alle vier Verfahren geeignet. Wobei natürlich nur das Betriebssystem Interrupts sperren und wieder freigeben kann - ein normales Anwendungsprogramm darf das (aus gutem Grund) nicht.
Die erste.
Nummer 2 beschreibt Verklemmungsauflösung, Nummer 3 ist die richtige Antwort für Verklemmungsvorbeugung, und Nummer 4 ist Quatsch. 
1 Like
Mir gefällt der Name des Pads, auch wenn ich persönlich keinerlei Vorbehalte gegen AuD hege. 
1 Like
Skipped August 2011
Hier darf das „immun“ als „geschützt vor dem Eintreten“ verstanden werden.
Anzunehmen wäre in dem Kontext soetwas wie die Scheduling-Ressourcen der CPU. Da kooperatives Scheduling auf der freiwilligen Abgabe der Kontrolle basiert, erfolgt hier kein Schutz.
Antwort 1 ist nicht ganz richtig. Es heißt nicht zwingend, dass die CPU etwas besseres zu tun hat. Vielleicht befindet sie sich auch gerade in einer (hoch priorisierten) Interruptbehandlung und hat gar keine Möglichkeit etwas mit höherer Priorität zu tun.
Antwort 4 ist korrekt.
1 Like
Journaling sorgt dafür, dass man das Dateisystem wieder in einen konsistenten Zustand bekommt, selbst wenn mitten in einer komplexen Operation der Strom ausfällt oder das System abschmiert. Es schützt nicht vor Datenverlust oder -verfälschung, wenn das Speichermedium einen Hau hat.
CPU-Schutz bedeutet, dass niemand die CPU monopolisieren kann. Bei kooperativem (d. h. nicht-verdrängendem) Scheduling ist das nicht gewährleistet, denn da kann ein Programm durch eine simple Endlosschleife dafür sorgen, dass nie wieder jemand anders drankommen wird.
Während einer Interrupt-Behandlung darf man auf gar keinen Fall passiv warten, das wird fast sicher zu einer Verklemmung führen!
Gemeint ist Folgendes: Wenn ich davon ausgehen kann, dass meine Wartezeit im Regelfall nur sehr kurz sein wird, dann lohnt sich das Schlafenlegen nicht, denn ich werde wahrscheinlich sofort wieder geweckt werden. Schlafenlegen und Aufwachen sind ja nicht kostenlos, sondern erfordern einiges an Aufwand (u. a. Kontextwechsel in den Kern). In so einem Fall dreht man lieber ein paar CPU-Takte aktiv Däumchen, bis das erwartete Ereignis eintritt.
Antwort 4 ist in der Tat korrekt.
2 Likes
-.- Das ganze war etwas intuitiver als man gerade BS gehört hatte. Selbstverständlich war das Blödsinn meinerseits. Sorry
Vielen Dank, dass ihr so schnell den Großteil der Fragen (bis auf den August 2011 Teil) beantworten konntet. Ich werde die Antworten mal durchdenken und melde mich vllt nochmal, wenn noch Unklarheiten bestehen.
Das haben wir ja gerade nebenan geklärt.
Variante 1 ist eindeutig besser. Stell dir vor, eine Seite aus dem gemeinsam genutzten Segment wird auf die Platte ausgelagert. Dann müsste man in Variante 2 gleich in mehreren Seitentabellen das Present-Bit anpassen - und zwar atomar, nicht dass ein Prozess auf diese Seite zugreift, während die eine Tabelle schon angepasst ist und die andere noch nicht. Mit duplizierten Seitentabellen handelt man sich jede Menge solcher Probleme ein.
Wenn man nur eine gemeinsame Seitentabelle verwendet, ist das alles kein Problem.
Das Einsortieren ist der springende Punkt. Wenn ein winziger Restblock übrig bleibt, muss der ganz ans Ende angehängt werden, und dann muss man tatsächlich einmal über die gesamte Liste rattern.
Wir wollen zusätzlich noch das Basisregister sehen, das auf den Beginn der Seitentabelle zeigt. Irgendwoher muss die MMU ja wissen, wo die Tabelle für den aktuellen Prozess im Speicher liegt. Bei jedem Adressraumwechsel wird das Basisregister entsprechend neu gesetzt.
Kann mir jemand die Antwort auf folgende Frage beantworten?
Virtualisierung kann als Maßnahme gegen Verklemmungen genutzt
werden. Warum?
1.Im Fall einer Verklemmung können zusätzliche virtuelle Betriebs-
mittel neu erzeugt werden. Diese können dann eingesetzt werden,
um die fehlenden physikalischen Betriebsmittel zu ersetzen.
2.Durch Virtualisierung ist ein Entzug von physikalischen Betriebsmitteln mög-
lich, obwohl dies auf der logischen Ebene unmöglich ist.
3.Eine Verklemmungsauflösung ist einfacher, weil virtuelle Betriebsmittel jeder-
zeit ohne Schaden entzogen werden können.
4.Durch Virtualisierung kann man über Abbildungsvorgänge Zyklen, die auf der
logischen Ebene vorhanden sind, auf der physikalischen Ebene auflösen.
Ich hätte auf 2. getippt
So isses.
hi die aufgabe ist aus März2009 die Aufgabe 2
kann mir jmd sagen ob das was ich da fabriziert habe so ungefähr passt, bzw ob folgende Sachen stimmen:
-das mit pthread und dem Ringbuffer
(dass die Arbeiter-Threads bei leerem Puffer passiv warten)
-die Komandoverarbeitung in ftpConn
( die bekommt einen Batzen komandos:(QUIT= Verbindung beenden, GET datei= getFile() aufrufen, LIST directory= listDir() aufrufen)
-stimmen die ganzen socketaddresswerte
Schon mal Herzlichen Dank wenn sich jmd die mühe macht
/* includes */
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <pthread.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <dirent.h>
/* Funktionsdeklarationen, Makros, globale Variablen */
static void *tstart(void *arg);
static void ftpConn(FILE *sockp);
static void getFile(FILE *sockp, const char *filename);
static void listDir(FILE *sockp, const char *dirname);
#define BUF_SIZE 12
#define PORT 21
#define MAX_CON 8
struct rbuffer{
FILE *buf[BUF_SIZE];
int read,write,toread,towrite;
};
struct rbuffer rbuf;
/* Funktion main */
static int main(char *args[]) {
/* Variablendefinitionen */
int anz_threads;
int port=PORT;
int max_cons=MAX_CON;
/* Argumente prüfen und auswerten */
anz_threads=atoi(args[0]);
if(anz_threads==0){
perror("ungueltiges Argument");
exit(1);
}
/* Synchronisation vorbereiten */
rbuf.read=0;
rbuf.toread=0;
rbuf.write=0;
rbuf.towrite=BUF_SIZE;
static pthread_mutex_t bl= PTHREAD_MUTEX_INITIALIZER;
static pthread_cond_t buf_empty= PTHREAD_COND_INITIALIZER;
pthread_mutex_init(&bl,NULL);
pthread_cond_init(&buf_empty, NULL);
/* Thread-Pool erzeugen */
{
int i;
for(i=0;i<anz_threads;i++){
pthread_t pid;
if(errno=pthread_create(&pid,NULL,(void *)tstart,NULL){
perror("pthread_create");
exit(1);
}
}
}
/* Server-Socket oeffnen und Verbindungsannahme vorbereiten */
int ssock;
struct sockaddr_in6 saddr;
if((ssock=socket(PF_INET6,SOCK_STREAM,0))==-1){
perror("socket");
exit(1);
}
saddr.sin6_family=AF_INET6;
saddr.sin6_addr.s_addr=htol(in6addr_any);
saddr.sin6_port=htons(port);
if(bind(ssock,(struct sockaddr *)&addr,sizeof(saddr)==-1){
perror("bind");
exit(1);
}
if(listen(ssock,max_cons)==-1){
perror(listen);
exit(1);
}
/* Server-Schleife: Verbindungen annehmen und bearbeiten */
int csock;
struct sockaddr caddr;
socklen_t caddrlen= sizeof(caddr);
FILE *fp;
while(1){
if((csock=accept(ssock,&caddr,&caddrlen))==-1){
perror("accept");
continue;
}
if((fp=fdopen(csock,"a+"))==NULL){
perror("fdopen");
exit(1);
}
if(rbuf.towrite<1){
fprintf(fp,"Server Ueberlastet");
fclose(fp);
continue;
}
pthread_mutex_lock(&bl);
rbuf.buf[rbuf.write]=fp;
rbuf.write=(rbuf.write++)%BUF_SIZE;
pthread_cond_broadcast(&buf_empty);
rbuf.towrite--;
pthread_mutex_unlock(&bl);
rbuf.toread++;
}
} /* Ende Funktion main */
/* Hauptschleife der Arbeiter-Threads: Funktion tstart */
static void *tstart(void *arg)
{
FILE *sockp;
while(1){
while(rbuf.toread<1){
pthread_cond_wait(&buf_empty,&bl);
}
pthread_mutex_lock(&bl);
sockp=rbuf.buf[rbuf.read];
rbuf.read=(rbuf.read++)%BUF_SIZE;
pthread_cond_broadcast(&buf_empty);
rbuf.toread--;
pthread_mutex_unlock(&bl);
rbuf.towrite++;
ftpConn(sockp);
}
} /* Ende Funktion tstart */
/* Auftragsentgegennahme: Funktion ftpConn */
static void ftpConn(FILE *sockp)
{
char word[1024];
int c,i,n=0;
char *quit="QUIT", *get="GET", *list="LIST";
for(i=0;(c=getc(sockp))!=EOF&&i<1024;i++){
if(c!=' '){
word[n]=(char)c;
n++
}else{
if(strncmp(word,quit,4)==0){
fclose(sockp);
exit(0);
}else if(strncmp(word,get,3)==0){
for(n=0;(c=getc(sockp))!=' '&&n<1023;n++){
word[n]=(char)c;
i++;
}
word[n]='\0';
getFile(sockp,word);
n=0;
}else if(strncmp(word,list,4)==0){
for(n=0;(c=getc(sockp))!=' '&&n<1023;n++){
word[n]=(char)c;
i++;
}
word[n]='\0';
listDir(sockp,word);
n=0;
}
}
}
fclose(sockp);
exit(0);
} /* Ende Funktion ftpConn */
/* Kommandobearbeitung: Funktion getFile */
static void getFile(FILE *sockp, const char *filename)
{
FILE *fp;
int c;
if((fp=fopen(filename,"r")==NULL){
fprintf(sockp,"Datei konnte nicht geoeffnet werden\n");
exit(1);
}
while((c=getc(fp))!=EOF){
putc(c,sockp);
}
if(ferror(fp)){
fprintf(sockp,"Fehler beim lesen der Datei\n");
}
fclose(fp);
} /* Ende Funktion getFile */
/* Kommandobearbeitung: Funktion listDir */
static void listDir(FILE *sockp, const char *dirname)
{
DIR *dir;
struct dirent *entry;
if((dir=opendir(dirname))==NULL){
fprintf(sockp,"Verzeichnis konnte nicht geoeffnet werden");
exit(1);
}
while(errno=0,(entry=readdir(dir))!=NULL){
fprintf(sockp,"%s\n",entry->d_name);
if(errno!=0){
fprintf(sockp,"Es ist ein Fehler beim Laden des Verzeichnis aufgetreten\n");
exit(1);
}
}
closedir(dir);
} /* Ende Funktion listDir */vielleicht eine etwas blöde Frage, aber müsste man nicht alleine schon für den Ringpuffer folgendes machen?
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <pthread.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <dirent.h>
int size = 20;
static int *mutBuffer[size];
volatile int putCounter, getCounter;
putCounter = getCounter = 0;
static volatile int putGuard, getGuard, waiter;
putGuard = size;
getGuard = waiter = 0;
pthread_mutex_t pGm;
pthread_cond_t pGc;
pthread_mutex_t gGm;
pthread_cond_t gGc;
pthread_mutex_t wGm;
pthread_cond_t wGc;
/*
Put(value){
P(putGuard);
mutBuffer[putCounter++] = value;
V(getGuard);
}
*/
Put(value){
//P(putGuard)
pthread_mutex_lock(&pGm);
while(putGuard <= 0){
pthread_cond_wait(&pGc, &pGm);
}
putGuard --;
pthread_mutex_unlock(&pGm);
mutBuffer[putCounter++];
//V(getGuard)
pthread_mutex_lock(&gGm);
getGuard++;
pthread_cond_broadcast(&gGc);
pthread_mutex_unlock(&gGm);
}
/*
Get(){
P(wait);
P(getGuard);
int result = mutBuffer[getCounter++];
V(putGuard);
V(wait);
}
*/
Get(){
//P(waiter)
pthread_mutex_lock(&wGm);
while(waiter <= 0){
pthread_cond_wait(&wGc, &wGm);
}
waiter --;
pthread_mutex_unlock(&wGm);
//P(getGuard)
pthread_mutex_lock(&gGm);
while(getGuard <= 0){
pthread_cond_wait(&gGc, &pGm);
}
getGuard --;
pthread_mutex_unlock(&gGm);
mutBuffer[getCounter++];
//V(putGuard)
pthread_mutex_lock(&pGm);
getGuard++;
pthread_cond_broadcast(&pGc);
pthread_mutex_unlock(&pGm);
//V(waiter)
pthread_mutex_lock(&gGm);
waiter++;
pthread_cond_broadcast(&gGc);
pthread_mutex_unlock(&gGm);
}
[quote=[hedgehogs dilemma = 42]]
vielleicht eine etwas blöde Frage, aber müsste man nicht alleine schon für den Ringpuffer folgendes machen?
[/quote]
Nein, du sollst ja kein extra Ringbuffermodul schreiben, sondern einfach intern einen Ringbuffer verwenden. Wenn du ein extra Modul schreiben sollst, wird das in den Kommentaren auch schon irgendwo auftauchen, dass du das hier implementieren sollst.
das meinte ich nicht - aber man müsste das was ich gemacht hab praktisch in ein inline buffer übertragen - find ich erlich gesagt n bisl viel für ne Klausur
Sorry, falls ich mich grade zu dumm zum Codelesen anstelle, bin etwas vollgefressen und daher müde, aber: Seh ich das richtig, dass du quasi mehrere Semaphoren mittels Mutex und Bedingunsvariablen nachbaust? Das ist wirklich Overkill.
Es genügt, per Mutex die anderen Threads auszusperren während man seine Lese-/Schreib-Operation macht und danach mit der Bedingungsvariable eventuell wartenden Threads zu signalisieren, dass sie aufwachen können.
Synchronisation bei vollem Buffer ist hier gar nicht nötig, der Server weist die Anfrage dann ja einfach ab.
hmm…ich glaub ich hab das ringpuffer konzept noch nicht komplett verstanden.
Wie sieht den ein Ringpuffer aus, der mit Sems arbeitet und nicht so n overkill ist wie meiner?
Ah, sorry, da hast du mich falsch verstanden.
Ich meinte, Semaphore nachzubauen ist für diese Aufgabe ein Overkill, da das nicht verlangt ist und einfacher Ausschluss, so wie blubbbrezn das implementiert hat, eben genügt, um die kritischen Abschnitte dieser Aufgabe zu schützen.
In SP implementiert man allerdings einen Ringbuffer mit Semaphoren, wenn ich mich grade nicht täusche. Da ist deine Lösung auch korrekt und man braucht noch einen zusätzlichen 3. binären Semaphor, der die ganze Operation schützt, da sonst bspw. in deinem Beispiel in Zeile 86 zwei Lesethreads gleichzeitig [m]getGuard–;[/m] ausführen könnten, was bekanntlich ziemlich schief gehen kann.
aso, das war praktisch ne aufgabe die so in der form nichtmehr drankommt -hat mich nur verwirrt, aber so macht das natürlich sinn.