Threads synchronized

[banshee]

Hallo,

drei Fragen dazu:

1) Hat der synchronized-Modifier in diesem Snippet überhaupt Sinn?

/**
	 * Load preferences fresh from disk
	 */
	public synchronized void loadPreferences(String fname) {
		System.out.println("loading " + fname + "...");
		try {
			BufferedReader br = new BufferedReader(new FileReader(fname));
			String line;
			while ((line = br.readLine()) != null)
				parsePrefLine(line);
			br.close();
		} catch (FileNotFoundException fnf) {
			System.err.println("FILE NOT FOUND: " + fname);
		} catch (IOException e) {
			e.printStackTrace();
		}
	}

So wie ich das sehe, ist die einzige Resource, auf die möglicherweise gleichzeitig zugegriffen wird, ein und dasselbe File. Da dieses aber nur gelesen wird und jeder Thread sein eigenes Handle darauf bekommt(?) sind multithread-Zugriffe doch trotzdem voneinander unabhängig oder nicht? Kann man sich das also nicht sparen?

2) Gibt es da einen Trick oder ein Schema, um keinen erforderlichen Mutex zu vergessen? Auf welche Zugriffsarten muss man da achten?

3) Wie groß ist der Overhead von synchronized-Modifiern, die man nicht braucht? Was passiert da intern?

Danke euch!

 

[Gucky]

Synchronized macht nur Sinn, wenn geschrieben wird. Ich weiß allerdings nicht, was in parsePrefLine(String) passiert. Womöglich wird dort geschrieben.

Wie schon oben gesagt, sind Schreiboperationen kritisch und müssen synchronisiert werden.

Wenn nur ein Thread auf die Ressource zugreift, passiert noch nicht allzu viel. Wenn aber zwei oder mehr versuchen darauf zuzugreifen, dann werden alle so lange gestoppt, bis der Erste fertig ist. Dann kommt der Zweite und so weiter.

 

[banshee]

Wenn nur ein Thread auf die Ressource zugreift, passiert noch nicht allzu viel. Wenn aber zwei oder mehr versuchen darauf zuzugreifen, dann werden alle so lange gestoppt, bis der Erste fertig ist. Dann kommt der Zweite und so weiter.

Das funktioniert bei threadsicherer Implementierung so. Ansonsten herrscht da doch undefiniertes Verhalten?!

parsePrefsLine ist liest auch nur aus. Falls die Funktion doch schrieben würde, würde man ja auch eher sie synchronized setzen, anstatt die aufrufende Obermethode, oder?

/e: Halt, das synchronized macht doch Sinn, da es in der Klasse auch eine Methode gibt, die auszulesenden Informationen schreibt. Ich dachte, synchronized verhindert nur gleichzeitigen Zugriff auf die jeweilige Methode, aber stattdessen sperrt das ja das ganze Objekt gegen Multithread-Zugriffe.

 

[Gucky]

So meinte ich das. Bei nicht synchronisierten Objekten kann es sein, dass der Thread die Datei einließt, unterbrochen wird, ein anderer Thread die Datei einließt, irgendwas macht, unterbrochen wird und der Erste trotzdem mit seinem Wert weiterarbeitet, obwohl der Wert schon verändert wurde.
Der Overhead hält sich, denke ich mal, in Grenzen. Allerdings müssen diese Ressourcen aktiv gesperrt werden, was bedeutet, dass die ganze Zeit irgendwas aufpassen muss. Und das kostet Performance. Ein Grund, aus dem der Vector von der ArrayList abgelöst wurde.

Eigentlich schon. Ich hab aber trotzdem ich nur Hobbyprogrammierer bin schon die tollsten Dinge gesehen.

Das Objekt oder die Ressource, auf die zugegriffen wird?