Fachrat Informatik - Forum
FACHSPEZIFISCHE DISKUSSIONEN
Grundlagen der Informatik
Fragen zu Programmieren II
Date of registration: Dec 11th 2001
Location: Hämelerwald
Occupation: Wissenschaftlicher Mitarbeiter (Forschungszentrum L3S, TU Braunschweig)
Monday, August 19th 2002, 8:18pm
Da die Wahrscheinlichkeit für Fehler, die aus der nicht vorhandenen Synchronisierung resultieren, bei kürzerer Laufzeit des Programms unwahrscheinlicher ist, passieren diese Fehler bei kleinen Werten für das zweite Argument natürlich seltener. Wenn du das Programm allerdings ein paar Mal z. B. mit den Parametern 3 und 10000 aufrufst, wirst du feststellen, daß auch dann eine Ausgabe zu sehen ist, also Fehler auftreten.
Quoted
Original von MAX
Erstens, es ist für mich nicht ganz klar, warum die Ausgabe für kleinere Argumente nicht erfolgt. Z.B. funktioniert der Aufruf java Caller 3 100000 einwandfrei und man erhält eine ähnliche Ausgabe wie auf der Folie. Sobald der zweite Argument kleiner als 100000 ist, gibt es gar keine Ausgabe. Warum ist das so?
Ist denke ich ein Fehler im Skript. Die Methode call() müßte folgendermaßen ausehen:
Zweitens, man möchte erreichen, dass die Threads "korrekt" arbeiten. Dafür synchronisieren wir kritische Stellen. Wie in der Folie beschrieben ist, gibt es zwei Möglichkeiten, entweder die Methode oder die Objektvariable, die uns kritisch erscheint, zu synchronisieren. Erste Möglichkeit führt bei mir nur zu einem bedingten Erfolg. D.h., dass einige Zahlen trotzdem nicht in der richtigen Reihenfolge erscheinen. Warum?
|
Source code |
1 2 3 4 |
synchronized static private void call() {
globalCallCount++;
memory.add(new Integer(globalCallCount));
}
|
Die zweite Möglichkeit funktioniert bei mir genau so wie im Skript auf Folie 774 beschrieben. Wahrscheinlich hast du einen Fehler in deinem Code. Kannst ja mal ein paar Ausschnitte posten.
Die zweite Möglichkeit führt gar zu keinem Erfolg, das Program hängt sich auf, was offensichtlich an der while Schleife in der main Methode liegt, kommentiert man sie aus, gibt es wieder keine Ausgabe. Warum?
Monday, August 19th 2002, 8:40pm
|
|
Source code |
1 2 3 4 5 6 7 8 9 10 |
private
void
call()
{
synchronized(memory)
{
globalCallCount++;
memory.add(new Integer(globalCallCount));
}
}
|
Date of registration: Dec 11th 2001
Location: Hämelerwald
Occupation: Wissenschaftlicher Mitarbeiter (Forschungszentrum L3S, TU Braunschweig)
Monday, August 19th 2002, 9:12pm
Sollte eigentlich nicht passieren. Probier' mal kleinere Werte für den zweiten Parameter aus (so klein, daß das Programm zum Ende kommt) und erhöhe diesen dann schrittweise. Wahrscheinlich mußt du einfach nur länger warten.
Original von MAX
Das erste Problem ist jetzt klar geworden. Ich hatte etwas anderes zuvor gedacht. Bei dem Problem 2a (ich mache also call() Methode zu static) kommt das Programm nicht zum Ende (Aufhänger).
Sieht richtig aus. Kontrolliere mal deinen kompletten Code - ist der auch wirklich identisch mit dem unter http://www-a2.informatik.uni-hannover.de…lltexte/Caller/? (mit Ausnahme der synchronized-Änderung natürlich)
Beim Problem 2b habe ich auch genauso, wie im Script gemacht, also die Methode abgeschrieben. Trotzdem ein Aufhänger. Hier ist ein ausschnitt:
[...]
Die while-Schleife ist IMHO vollkommen in Ordnung. Das Problem liegt mit Sicherheit woanders.
Zur while Schleife: Es ist mir klar, dass man sie nicht einfach so weglassen kann, aber vielleicht ist sie nicht so gut auf das Programm abgestimmt worden. Das heißt, man sollte lieber eine andere while Schleife benutzen. Wie sie aussehen soll, habe ich keine Ahnung.
Date of registration: Dec 11th 2001
Location: Hämelerwald
Occupation: Wissenschaftlicher Mitarbeiter (Forschungszentrum L3S, TU Braunschweig)
Monday, August 19th 2002, 9:31pm
Das sollte eigentlich nicht passieren. Auch ohne funktionierende Synchronisierung sollte das Programm zum Ende kommen -- dann sollten jedoch in der Regel Synchronisierungsfehler auftauchen.
Original von MAX
Wenn ich nur die Methode call() synchronisiere, sie aber nicht statisch mache, dann kommt das Programm nicht zum Ende.
So soll es sein.
Nachdem ich sie statisch gemacht habe, funktioniert alles einwandfrei.
Die Methode call() muß dann aber nicht static sein. Es sollte auch so funktionieren. Irgendwas läuft bei dir gewaltig schief. Kontrolliere doch bitte nochmal deinen *kompletten* Quellcode (oder stelle ihn irgendwo zum Download, damit wir ihn uns mal anschauen können).
Wenn ich nur die Objektvariable synchronisiere und dabei die call() Methode auch statisch mache, funktioniert auch alles wunderbar.
Das Beispiel sollte ja auch die *Probleme* von unsynchronisiertem Multithreading veranschaulichen und kein Beispiel für Multithreading an sich sein. Und dafür wird man kaum ein "minimaleres" Beispiel finden.
Ich muss aber noch was zu diesem Programm sagen. Ich finde dieses Beispiel keine gute Einführung für Multithreading, denn hier sieht man leider nicht so gut, was Multithreading ist und wie es arbeitet.
Das sagt tby ja schon seit der ersten Vorlesung. Und damit hat er IMHO vollkommen recht. Die Vorlesung soll Einblicke geben und Stichworte liefern, um sich selber mit den Themen beschäftigen zu können. Ein umfassender Programmierkurs sollte (und konnte!) es ja nie sein.
Ich denke, dass ich ohne zusätzliche Literatur nur an diesem Beispiel gar nicht verstanden hätte, wie Multithreading funktioniert. Vielleicht war das auch die Absicht des Autors, dass wir zu anderen Quellen greifen, um das zu verstehen.
Monday, August 19th 2002, 9:45pm
Die Methode call() muß dann aber nicht static sein. Es sollte auch so funktionieren. Irgendwas läuft bei dir gewaltig schief. Kontrolliere doch bitte nochmal deinen *kompletten* Quellcode (oder stelle ihn irgendwo zum Download, damit wir ihn uns mal anschauen können).
Das Beispiel sollte ja auch die *Probleme* von unsynchronisiertem Multithreading veranschaulichen und kein Beispiel für Multithreading an sich sein. Und dafür wird man kaum ein "minimaleres" Beispiel finden.
Wednesday, August 28th 2002, 5:19pm
Original von MAX
Mit der Methode stop() kann aber ein Thread auch gestopt werden. Die Methode ist aber als deprecated erklärt. Trotzdem, ist das nicht ein direktes Stopen eines Threads???
Sunday, September 1st 2002, 7:49pm
)
Hat da vielleicht wer ein bsp für? Ein ganz kurzes wenns geht. Muß ich mir ja auch merken können Date of registration: Dec 11th 2001
Location: Hämelerwald
Occupation: Wissenschaftlicher Mitarbeiter (Forschungszentrum L3S, TU Braunschweig)
Monday, September 2nd 2002, 10:41am
Es gibt nicht nur eine Wrapper-Klasse. Mit Wrapper bezeichnet man eine ganze Gruppe von Klassen, nämlich solche, die einen bestehenden Datentyp "umhüllen" und eine neue Schnittstelle zu diesem anbieten.
Original von Tara
1.) Ist die Wrapper-Klasse so eine Art Platzhalter?
Man könnte im Prinzip auch schreiben: "Der tatsächliche Typ eines Objektes bestimmt, welche Methode ausgeführt wird" (wenn man davon ausgeht, daß Methoden mit gleichem Namen, aber unterschiedlicher Signatur, etwas verschiedenes sind). Ein Methodenrumpf ist der Teil der Methode, in dem steht, "was gemacht wird". Siehe dazu auch die Folien 33 und 34 im Skript.
2.)Der tatsächliche Typ eines Objektes bestimmt, welcher Methodenrumpf ausgeführt wird. Was ist damit gemeint? Also eigentlich versteh ich daran nur das Wort Methodenrumpf nicht
Am besten, du schaust dir das Beispiel auf den Folien 196 bis 214 im Skript an. Oder besser: Programmiere es nach und probier' es aus. Das ist wahrscheinlich sinnvoller als hier das Prinzip lang und breit zu erklären. Falls du mit dem Beispiel Probleme haben solltest, kannst du dich ja nochmal melden.
3.) Die tatsächlich aufgerufenen Methode kann also je nach Typ des Objektes variieren, auch wenn der Aufruf stehts gleich ist.
Auch hier solltest du dich mit o. g. Folien im Skript beschäftigen.
4.) Worin liegt der Unterschied zwischen deklariertem und tatsächlichem Typ?
|
|
Source code |
1 2 3 |
String objone = "Test"; Object objtwo = objone; System.out.println(objtwo.toString()); |
Monday, September 2nd 2002, 10:59am
es geht eigentlich darum, dass du in java beliebig viele methoden mit gleichem namen definieren kannst. diese methoden müssen sich nur in ihrer signatur unterscheiden. d.h.:
2.)Der tatsächliche Typ eines Objektes bestimmt, welcher Methodenrumpf ausgeführt wird. Was ist damit gemeint? Also eigentlich versteh ich daran nur das Wort Methodenrumpf nicht
aus dem javabuch von g. krüger:
Unter der Signatur einer Methode versteht man ihren internen Namen. Dieser setzt sich aus dem nach außen sichtbaren Namen plus codierter Information über die Reihenfolge und Typen der formalen Parameter zusammen. Die Signaturen zweier gleichnamiger Methoden sind also immer dann unterscheidbar, wenn sie sich wenigstens in einem Parameter voneinander unterscheiden.
Monday, September 2nd 2002, 11:24am
Original von Joachim
Trotzdem ein kurzes Beispiel:
Source code
Der deklarierte Typ von objtwo ist nun Object, der tatsächliche aber String.
Date of registration: Dec 11th 2001
Location: Hämelerwald
Occupation: Wissenschaftlicher Mitarbeiter (Forschungszentrum L3S, TU Braunschweig)
Monday, September 2nd 2002, 11:40am
Es sind keine Hilfsmittel zugelassen. Sollte es Aufgaben geben, zu denen man die API-Doc benötigt, werden wir laut Aussage von tby einen entsprechenden Ausschnitt aus derselben bekommen.
Original von chefstatist
welche Hilfsmittel sind in der Klausur eigentlich zugelassen? Darf man die Kurzreferenz wieder benutzen?
