vector, synchronized und mehrere methoden

[klaus dieter]

hallo zusammen,

ich bin gerade dabei ein programm in java zu realisieren, bei dem es einen vector existiert, in dem so ziemlich alle daten gespeichert werden.
diesen vector habe ich ein eine separate klasse gepackt und verschiedene methoden zum schreiben in den vector, lesen aus den vector und suchen im vector implementiert.
nur bin ich mir jetzt nicht ganz sicher, das meine gedanken zur sicherstellung der zugriffe richtig ist. denn ich muss 100% sicherstellen, das nicht zwei von diesen methoden gleichzeitig auf diesen vector zugreifen können. nun bin ich einfach mal hingegangen und habe alle methode mit synchronized definiert.
aber wenn ich mir das jetzt so recht überlege, weis ich nicht recht, ob das ausreicht.

denn wenn suchfunktionen zum beipsiel den vector durchsuchen, ist das ja nur eine anreihung von get methoden des vectors. diese sind zwar schon von der definition der vector-klasse synchronizert, aber reicht das ???
um die suche zu realisieren, habe ich eine for-scheife definiert, die abbricht, wenn i vec.size() erreicht hat. das ist ja noch alles ok. nun ist es aber theoretisch möglich, das von einem anderem object die methode zum hinzufügen eines element zu dem vector aufgerufen wird, solange der vector noch durchsucht wird und schon stimmt doch die größe des ermittelten vec.size() nicht mehr und die suchfunktion stimmt nicht mehr.

kann ich irgendwie sicherstellen, das nur eine methode der klasse aktiv aufgerufen werden kann oder gibt es da vielleicht noch eine ganz andere möglichkeit dafür???

für jede hilfe bei diesem problem bin ich sehr dankbar...

 

[mariopetr]

bis tiger

public class AClass
{
	public Vector vector;
.
.
public void foo()
{
	synchronized(vector)
	{
		//hier ist exclusives lesen/schreiben moeglich
	}
}
public void bar()
{
	synchronized(vector)
	{
		//hier ist auch exclusives lesen/schreiben moeglich
	}
}
}

ab tiger sollte man eine implementierung von lock (uu mit conditions) beutzen.

 

[klaus dieter]

danke funktioniert bestens...

 

[René Link]

Hi,

warum macht ihr euch so ein Umstand?
Wenn ich die Frage richtig verstanden habe,
denkst du, dass bei einer for-Schleife die Abbruchbedingung
nicht mehr stimmt falls ein anderer Thread den Vector verändert.

Das ist nicht ganz richtig.
Also folgender Code

for(int i = 0; i < vector.size(); i++){

    Object obj = vector.elementAt(i);
}

Die Methoden im Vector sind folgendermaßen implementiert

    public synchronized int size() {
	return elementCount;
    }

    public synchronized boolean add(Object o) {
	modCount++;
	ensureCapacityHelper(elementCount + 1);
	elementData[elementCount++] = o;
        return true;
    }

    public boolean remove(Object o) {
        return removeElement(o);
    }

    public synchronized boolean removeElement(Object obj) {
	modCount++;
	int i = indexOf(obj);
	if (i >= 0) {
	    removeElementAt(i);
	    return true;
	}
	return false;
    }

Bei jedem Schleifendurchlauf wird size() erneut aufgerufen. Wenn inzwischen
ein anderer Thread ein Objekt hinzugefügt hat, bekommt die Schleife die Änderung mit.

Das einzigste Problem kann entstehen, wenn ein Thread ein Objekt entfernt.
Nehmen wir an du hättest 5 Elemente im Array. Deine index-Variable der Schleife
zeiget auf das Erste.

# <
#
#
#
#

Der Schleifenkörper wird ausgeführt und das erste Element gelesen.

+ <
#
#
#
#

Jetzt kommt der nächste Schleifendurchlauf. Die Bedingung ist war, da sich die größe nicht
geändert hat. Also wird die Index-Variable um eins hochgezählt.

+
# <
#
#
#

Wenn jetzt ein zweiter Thread an die Reihe kommt und das erste Element entfernt,
überspringt die for-Schleife ein Element. Weil das Element auf Position 2, auf das die
Index-Variable zeigt, auf die freigewordene Position 1 geschoben wird.

2. Thread löscht 1. Element

#
# <
#
#

Wenn du diesen Fall auch ausschließen willst kommst du nicht drumherum die for-Schleife
zu synchronisieren.

synchronized (vector) {
  for(int i = 0; i < vector.size(); i++){

     Object obj = vector.elementAt(i);
  }
}

Ansonsten würde ich die Vector-Klasse einfach benutzen. Um so mehr synchronisierte Blöcke oder Methoden
du hast, desto mehr Verwaltungsaufwandt muss die Java-VM bearbeiten. Die Performance leidet also
darunter. Daher -> nur soviel synchronisieren wie nötig - nicht wie möglich.