FB18 - Das Forum für Informatik

fb18.de / Diplom Informatik / Unterbereich Grundstudium / Praktische Informatik

P2/3 "restfragen"

P2/3 "restfragen" 2005-02-04 15:56
pazz
moin!
ich ham am mittwoch p2/3 prüfung bei herrn Züllighoven, und beim durchsehen der protokolle ist mir noch folgendes schleierhaft geblieben:

1) was sind ST-Diagramme?
kam meines erachtens nie in p3 vor, es gibt aber eine frage dazu in verbindung mit petrinetzen..
sind das s(t) ? diagramme zur visualisierung von echtzeitsystemen?
wofür steht dann das s?

2)muss ich bei der beschreibung von Axiomen bei ADT's genau wissen wie seine Syntax lautet und wie sie gemeint ist?
denn das ist mir beim lesen des scriptes nicht klar geworden:
enqueue: QUEUE[T] -> T -> QUEUE[T]

"eine schlange von Elementen vom typ T .. ich rufe eine operation 'enqueue' auf mit parameter vom Typ T ?!? und erhalte eine schlage" ?!?

ich weiss,sind jetzt nicht mehr so lebenswichtige sachen, aber wär ja trozdem schön das mal zu wissen :)
THX!

pazz

Re: P2/3 "restfragen" 2005-02-04 16:29
korelstar
1) was sind ST-Diagramme?
kam meines erachtens nie in p3 vor, es gibt aber eine frage dazu in verbindung mit petrinetzen..
sind das s(t) ? diagramme zur visualisierung von echtzeitsystemen?
wofür steht dann das s?
Ich würde jetzt spontan denken, dass ein S/T-Netz (kann man ja auch als Diagramm sehen) gemeint ist. Und S/T steht für Stellen/Transitionen, also einem handelsüblichen Petri-Netz. Dafür will ich aber keine Garantie übernehmen.

2)muss ich bei der beschreibung von Axiomen bei ADT's genau wissen wie seine Syntax lautet und wie sie gemeint ist?
denn das ist mir beim lesen des scriptes nicht klar geworden:
enqueue: QUEUE[T] -> T -> QUEUE[T]

"eine schlange von Elementen vom typ T .. ich rufe eine operation 'enqueue' auf mit parameter vom Typ T ?!? und erhalte eine schlage" ?!?
Das Skript ist da meiner Meinung nach ziemlich dämlich - der Pfeil sollte lieber ein Komma oder Kreuz für das kartesische Produkt sein. Da die ADTs nicht objektorientiert angesehen werden, muss den Operationen immer die Queue selbst auch mitgebenen werden. Im konkreten Fall heißt das, dass "enqueue" als Parameter eine Queue und eine Element erhält und dann eine neue Queue zurückgibt, in der das Element eingefügt wurde. D.h. die ursprüngliche Queue wird nicht verändert. Wenn man das ganze objektorientiert sehen würde, würden bei allen Prozeduren natürlich der Parameter Queue wegfallen und es würde oft keine Rückgabe geben. Die Operation "empty" wäre dann der Konstruktor des Objektes.

Re: P2/3 "restfragen" 2005-02-04 16:30
d-fence
ST-Diagramme aka Stellen Transitionen Diagramme aka Petrinetze


alles die gleiche scheisse ;)


mit der syntax kann ich dir nicht wirklich weiterhelfen, da ich bei neumann prüfung mache und dem reicht es wohl wenn du weisst was für operationen es gibt und was für typen benutzt werden.


viel spass noch beim lernen ^^



edit: *grml* zu langsam

Re: P2/3 "restfragen" 2005-02-04 16:39
Brokkoli
also eine vernünftige beschreibung der adts erhälst du da:
http://ivs.cs.uni-magdeburg.de/~dumke/EAD/Skript29.html
den link hatte fred hier auch schon gepostet.. in unserm script ist das leider sehr unvollständig (z.b. axiome und voraussetzungen werden nicht verwendet) und zum teil auch sehr merkwürdig formuliert..

Re: P2/3 "restfragen" 2005-02-04 23:17
georg
enqueue: QUEUE[T] -> T -> QUEUE[T]

Ja, diese Schreibweise ist etwas gewöhnungsbedürftig.
Ich würde das mal interpretieren wie in Haskell, da
würde man sich folgendermaßen Klammern denken:

enqueue: QUEUE[T] -> (T -> QUEUE[T])

Man denkt sich also enqueue so, als lieferte es zu einem
QUEUE[T] eine Abbildung, die wiederrum zu einem T eine andere
QUEUE[T] liefert. Insgesamt steckt man quasi ein QUEUE[T] und
ein T rein und bekommt ein QUEUE[T] heraus. Bedeuten soll's also
das gleiche wie

enqueue: QUEUE[T] x T -> QUEUE[T].

nur in obiger Schreibweise hat man enqueue sehr elegant durch
die Möglichkeit des Currying beschrieben.

Re: P2/3 "restfragen" 2005-02-05 11:16
Brokkoli
nur in obiger Schreibweise hat man enqueue sehr elegant durch
die Möglichkeit des Currying beschrieben.

ich dachte die zeiten wären endlich mal vorbei *g*

Re: P2/3 "restfragen" 2005-02-05 14:06
pazz
super! THX für die antworten!
wert mich gleich nochmal ranmachen..
pazz

Re: P2/3 "restfragen" 2005-02-06 20:05
Azrael
Neue Frage:

Bei den Prüfungsfragen, die Neumann ins Netz gestellt hat, steht auf Seite 33 unten, dass bei der 2-Phasen-Sperrsynchronisation unvermeidbar Verklemmungen auftreten können.

Auf der nächsten Folie (S. 34) steht unter "Maßnahmen zur Vermeidung von Deadlocks" Preclaiming - Vorabforderung aller Sperren. Also auch 2PL.

Hab ich da irgendetwas falsch verstanden?

Re: P2/3 "restfragen" 2005-02-06 21:24
Spaceman
Bei den Prüfungsfragen, die Neumann ins Netz gestellt hat, steht auf Seite 33 unten, dass bei der 2-Phasen-Sperrsynchronisation unvermeidbar Verklemmungen auftreten können.

Auf der nächsten Folie (S. 34) steht unter "Maßnahmen zur Vermeidung von Deadlocks" Preclaiming - Vorabforderung aller Sperren. Also auch 2PL.

Hab ich da irgendetwas falsch verstanden?

Ja ich muss zugeben, dass mich das auch verwirrt hat. Hier sind seine Folien sehr unschön aufgebaut. Also ich habe das jetzt so verstanden:
preclaiming != 2PL. Beim Preclaiming startet man ein Transaktion nur, wenn am Anfang alle Ressourcen frei sind. Also ist preclaiming meiner Ansicht schon ein sinnvolles Mittel der Deadlock-Vermeidung. Allerdings führt das dazu, dass viele Prozesse warten müssen und der Geschwindigkeitsvorteil durch Nebenläufigkeit verringert wird.
Beim 2Pl müssen nicht zwangläufig alle Resourcen am Anfang frei sei. 2Pl garantiert nur, dass die nebenläufig ausgeführten Transaktion serialisierbat sind

Re: P2/3 "restfragen" 2005-02-06 21:32
Anonymer User
Bei den Prüfungsfragen, die Neumann ins Netz gestellt hat, steht auf Seite 33 unten, dass bei der 2-Phasen-Sperrsynchronisation unvermeidbar Verklemmungen auftreten können.

Wie war nochmal die Url von Prüfungsfragen!?

Re: P2/3 "restfragen" 2005-02-06 21:34
Brokkoli
ja dadurch dass es beim 2pl eine "wachstumsphase" gibt, und nicht einen punkt an dem (ununterbrechbar) alle ressourcen gesperrt werden, kann ja genau das problem auftreten was davor beschrieben wurde mit dem gegenseitigen blockieren der ressourcen (also deadlocks)