Threadsafe FIFO-Array

[usrr]

Hallo,

ich bräuchte einen Array, in den ein Thread Werte speichert und ein anderer die Werte ausliest. Werte die zu erst gespeichert wurden, sollen auch als erstes gelesen werden.

Ich bin mir nicht sicher, ob das mit einer threadsicheren ArrayList geht.

erster Thread) arraylist.add(object);
zweiter Thread) falls size>0 dann object = arrayList.get(0)

Würde das so funktionieren?

 

[Gast2]

Das ganze nennt sich dann Array:
Queue (Java 2 Platform SE 5.0)

Die Implementierung die du suchst ist vermutlich: ArrayBlockingQueue (Java 2 Platform SE 5.0)

 

[usrr]

Danke, das sollte genau sein was ich gesucht habe.

 

[usrr]

[STRIKE]Folgendes Problem.

In Thread 1 stecke ich Objecte in die ArrayBlockingQueue:

queue.add(obj);

In Thread zwei frage ich ab:

while (!queue.isEmpty()) {
try {
queue.take();
} catch (InterruptedException e) {
}

Leider duplizieren sich einige Objecte. Woran liegt das?

EDIT:

Ich muss mich korrigieren. Durch einen Counter habe ich festgesetllt, dass sich die Anzahl der Objecte nicht verändert. Allerdings deren Inhalt.[/STRIKE]

 

[Joew0815]

queue.add(obj);

Kann es sein, das du das Object nach dem add noch veränderst?
(zeig mal plz. den Code)

PS.

while (!queue.isEmpty()) {...}

Würde ich nicht machen
Wenn der Thread gestartet wird bevor was in der Queue ist, wird er einfach beendet
und keiner arbeitet mehr die Queue ab

for(;;){
try {
queue.take();
} catch (InterruptedException e) {
}

und bei dem Thread dann:

setDeamon(true);

 

[usrr]

Die Objecte die ich rein gepackt habe, wurden tatsächlich vom System nachträglich verändert. Anders kann ich es mir nicht erklären. Nach dem ich die benötigten Daten mit einer eigenen Klasse übertragen habe, ging es dann.

Den Einwand mit dem Thread verstehe ich nicht ganz. Es läuft jetzt ja auch wunderbar ohne, dass schon etwas in der Warteschlange steht. Vielleicht war es aber auch ein Missverständnis. Was der Thread macht, ist regelmäßig die Queue abzufragen und wenn sie leer ist, dann soll es mit anderen Aufgaben weiter gehen.

 

[hüteüberhüte]

Warteschlange [...]

Bau dir eine wrapper class. Eine synchronized add method ruft notifyAll() auf, wenn etwas hinzugefügt wird. Die ebenfalls synchronized take() method ruft in einer Schleife wait() auf, solange die Queue leer ist.

 

[usrr]

Bau dir eine wrapper class. Eine synchronized add method ruft notifyAll() auf, wenn etwas hinzugefügt wird. Die ebenfalls synchronized take() method ruft in einer Schleife wait() auf, solange die Queue leer ist.

Aber dann würde doch der Thread der add aufruft, auch das notifyAll() auslösen. Das wäre nicht das was ich brauche.

 

[Marco13]

notifyAll? Ableiten und überschreiben? Krampf, genau DAS sollte ja nicht nötig sein! Beschreib' das Problem mal genauer, ggf. mit KSKB. Vielleicht solltest du nicht "add" aufrufen, sondern "offer" oder so (willst du ein ganz normales Producer-Consumer pattern?)

 

[hüteüberhüte]

Aber dann würde doch der Thread der add aufruft, auch das notifyAll() auslösen. Das wäre nicht das was ich brauche.

Wenn gerade kein Thread wartet, ist ein Aufruf von notify() oder notifyAll() wirkungslos. NUR wenn die Queue leer ist und ein Aufruf von take() erfolgt, wird gewartet

Wrapper class ist vielleicht die falsche Bezeichnung gewesen^^

Beschreib' doch mal genauer, welche Threads was machen. Eine ArrayBlockingQueue verhindert auch nur, dass etwas gleichzeitig eingefügt oder entnommen wird

 

[usrr]

Sorry, aber das Problem ist ja längst gelöst. Ich war mir auch sicher, dass ich den Thread auf gelöst, gesetzt hatte.

 

[hüteüberhüte]

Alles klar. Aber bisher ließ das Thema (für mich jedenfalls) noch einige Fragen offen. Wenn für dich das Thema gelöst/erledigt ist, ok..

 

[usrr]

Ja, das Thema lässt noch einige Fragen offen. Für mich ist es erstmal gelöst - wenn auch sehr wahrscheinlich nicht besonders effizient.

Bei meinem Post heute um 11:33 bin ich irrtümlich davon ausgegangen, dass es Probleme gibt. Ich habe dann aber gemerkt, dass die Probleme nicht durch die ArrayBlockingQueue verursacht wurden, sonden von den Objecten, die ich geadded habe. Diese wurden, warum auch immer, wohl von einem anderen Systemteil verändert und dadurch kam am Ende was anderes raus als ich erwartet hatte.

Statt mit einer ArrayBlockingQueue, funktioniert es übrigens genauso auch mit einer syncronisierten ArrayList.

Worum es eigentlich nur geht, ist einen Strom von Ereignis-Objecten, die ein Thread-A erzeugt, kollisionssicher in einen Thread-B zu streamen, der diese dann in der korrekten Reihenfolge abarbeitet. Mehr war gar nicht gefordert.