Discussion:
zeitabhängige HashMap
(zu alt für eine Antwort)
Olaf Eilers
2004-10-03 17:40:09 UTC
Permalink
Interessehalber, wie würdet Ihr eine HashMap implementieren, deren Werte
zeitabhängig sind, also z.B. Werte, die älter als 15 Minuten sind,
fliegen raus?

Gruss,
Olaf
Hendrick Kay
2004-10-03 17:54:42 UTC
Permalink
Post by Olaf Eilers
Interessehalber, wie würdet Ihr eine HashMap implementieren, deren Werte
zeitabhängig sind, also z.B. Werte, die älter als 15 Minuten sind,
fliegen raus?
Erzeuge eine Klasse, die eine Hashmap besitzt und für jeden Eintrag sich
das Einfügedatum merkt.

Nun brauchst du einen Thread, der alle 15 min diese (und vielleicht
andere Maps dieser Art) Map durchsucht und alle alten Einträge rausschmeißt.

Ciao
Hendrick
Stefan Ram
2004-10-03 18:03:10 UTC
Permalink
Post by Olaf Eilers
Interessehalber, wie würdet Ihr eine HashMap implementieren,
deren Werte zeitabhängig sind, also z.B. Werte, die älter als
15 Minuten sind, fliegen raus?
Beispielsweise träge (Zeit eines Eintrags wird erst bei Abruf
geprüft) oder auch als Runnable.
Peter Büttner
2004-10-03 18:07:02 UTC
Permalink
Post by Olaf Eilers
Interessehalber, wie würdet Ihr eine HashMap implementieren, deren
Werte zeitabhängig sind, also z.B. Werte, die älter als 15 Minuten
sind, fliegen raus?
Ich nehme mal an _genau_ 15 min brauchen es nicht sein.

Eine Map die an eine Map delegiert und sich kümmert, oder
ableiten, je nachdem was sonst noch so wichtig ist.
Immer die Einträge die neu reinkommen in eine
List/HashMap/WeakHashMap/WeakList schreiben, von diesem Container
je einen für 'jede Minute' anlegen und diese List of List alle Minute
durchgehen und dann mit Inhalt entsorgen.

Weak oder nicht Weak hängt wieder vom drumrum ab, vielleicht auch
SoftReferences.

Sollen Zugriffe die 15 Minuten wieder von vorne starten lassen?



Grüße
Peter
--
Shell&Jar : Individual icons for jars
jMineSweeper : extended
www.PeterBuettner.de
Olaf Eilers
2004-10-03 19:02:06 UTC
Permalink
Post by Peter Büttner
Ich nehme mal an _genau_ 15 min brauchen es nicht sein.
Braucht nicht genau zu sein, 15 min +/- 1 min wäre schon ok
Post by Peter Büttner
Sollen Zugriffe die 15 Minuten wieder von vorne starten lassen?
Ich versuche mich mal genauer auszudrücken, die javasprachlichen
Gepflogenheiten sind mir noch nicht ganz inne:

Von aussen benötige ich nur 2 Methoden, a) insert(String name) und b)
size().

insert fügt name ein, wenn name nicht vorhanden ist
size ist ja bekannt

Den remove, was sonst programmtechnisch gemacht wird, soll vom Objekt
selbständig gemacht werden und zwar nach einer definierten Zeit, also
z.B. 15 min. Also wird intern "name" mit zugehörigem Zeitstempel
gespeichert.

Wie das zeitgesteuerte entfernen von "name" realisiert wird, da habe ich
mir jetzt nur oberflächlich Gedanken gemacht.

Runnable implementieren und den Thread die angegebene Zeit schlafen
legen? TimerTask? Wie würde so etwas in Java am effizentesten programmiert.

Je nachdem, in welche Sprache ich gerade arbeite (zumeist
Scriptsprachen), würde ich es z.B. im Konstruktor einfach so machen:
setTimer(this.remove(), 15*60*1000);

Jeglicher Hinweis ist willkommen.

Gruss,
Olaf
Stefan Ram
2004-10-03 19:20:24 UTC
Permalink
Post by Olaf Eilers
Wie das zeitgesteuerte entfernen von "name" realisiert wird, da
habe ich mir jetzt nur oberflächlich Gedanken gemacht.
Das würde ich träge bei Aktivierung der Operation "size"
machen. Dann werden alle map.Keys() durchlaufen und
diejenigen, deren Eintrag zu alt ist, werden entfernt, bevor
dann mit super.size() die Größe ermittelt wird.
Stefan Ram
2004-10-03 19:34:37 UTC
Permalink
[2 quoted lines suppressed]
Das würde ich träge bei Aktivierung der Operation "size"
machen. Dann werden alle map.keySet() durchlaufen und
diejenigen, deren Eintrag zu alt ist, werden entfernt, bevor
dann mit super.size() die Größe ermittelt wird.
Peter Büttner
2004-10-03 19:45:55 UTC
Permalink
Post by Olaf Eilers
Post by Peter Büttner
Ich nehme mal an _genau_ 15 min brauchen es nicht sein.
Braucht nicht genau zu sein, 15 min +/- 1 min wäre schon ok
Post by Peter Büttner
Sollen Zugriffe die 15 Minuten wieder von vorne starten lassen?
Ich versuche mich mal genauer auszudrücken, die javasprachlichen
Von aussen benötige ich nur 2 Methoden, a) insert(String name) und b)
size().
insert fügt name ein, wenn name nicht vorhanden ist
size ist ja bekannt
Ahh, Objekte nur einmal. Kann man doch glatt übersehen.
Post by Olaf Eilers
Den remove, was sonst programmtechnisch gemacht wird, soll vom Objekt
selbständig gemacht werden und zwar nach einer definierten Zeit, also
z.B. 15 min. Also wird intern "name" mit zugehörigem Zeitstempel
gespeichert.
Dann würde ich es so machen wie beschrieben, also nicht für jedes der
Objekte einen Thread oder extra Zeitinfos. Sondern 15 Eimer wo jeweils
alle reinkommen und dann die Eimer reihum ausleeren.
Da ich die Einmaligkeit der Objekte übersah: du machst dann innen noch
ein Set wo du dir die Objekte merkst, also zweimal: im Set und in den
WasteBuckets.
Wenn du doch genauere Zeiten brauchst kannst du die ja statt ein Set
eine Map nehmen und die Zeit dranpappen.


Dein Verwalter hat einen Thread/Timer, der alle Minute aufwacht
(oder wenn mit size(),... gefragt wird und kümmert sich dann.
Frage ist halt was pasiert wenn nix abgefragt wird, ob die Objekte
dann alle dableiben (wenn du normale Referenzen hast räumt der GC
ja nix weg).

Kommt alles darauf an: was wie wo wieviele,...


Wie sieht dein interface aus?
insert()
size()
und kein
contains()
?
Nur String? baust du 'nen Chat wo du nur Namen brauchst?
Post by Olaf Eilers
Wie das zeitgesteuerte entfernen von "name" realisiert wird, da habe ich
mir jetzt nur oberflächlich Gedanken gemacht.
Runnable implementieren und den Thread die angegebene Zeit schlafen
legen? TimerTask? Wie würde so etwas in Java am effizentesten programmiert.
'effizent' dürfte kaum ein Problem sein.
Ausser du baust eine Map wo die Values die Zeiten sind und du alle 100ms
die ganze Map mit 100.000 Einträgen durchjoggst und nachsiehst ob nicht
doch was rauszuwerfen ist.
Post by Olaf Eilers
Je nachdem, in welche Sprache ich gerade arbeite (zumeist
^^^^^^ man hat es geahnt:-))
Post by Olaf Eilers
setTimer(this.remove(), 15*60*1000);
Nee, innen in der Klasse, alles kapseln. Von aussen ist nur
size(), insert() sichtbar.
Evtl. remove() removeAll() und contains()
Dann übergibst du im Constructor das intervall, und wenn du es
unbedingt brauchst das intervall per get/set abfrag- und änderbar.
Immer dran denken: yagni



Grüße
Peter
--
Shell&Jar : Individual icons for jars
jMineSweeper : extended
www.PeterBuettner.de
Paul Ebermann
2004-10-05 17:51:00 UTC
Permalink
Post by Olaf Eilers
Post by Peter Büttner
Ich nehme mal an _genau_ 15 min brauchen es nicht sein.
Braucht nicht genau zu sein, 15 min +/- 1 min wäre schon ok
Post by Peter Büttner
Sollen Zugriffe die 15 Minuten wieder von vorne starten lassen?
Ich versuche mich mal genauer auszudrücken, die javasprachlichen
Von aussen benötige ich nur 2 Methoden, a) insert(String name) und b)
size().
Den ganzen restlichen Collection-Kram brauchst du nicht?

(contains, iterator(), addAll(), ...)
Post by Olaf Eilers
insert fügt name ein, wenn name nicht vorhanden ist
size ist ja bekannt
Was soll passieren, wenn ein Objekt nochmal eingefügt
wird, nachdem es schon drin ist?

Soll es beim 15 min nach dem ersten oder nach dem letzten
Einfügen gelöscht werden?
(Ich gehe mal vom ersten aus, das ist einfacher zu
programmieren :-))

Ich mach das Löschen einfach beim Abfragen von
size() - so viel Overhead ist das nicht.


---
package de.dclj.paul.newsgroup;

/**
* Ein NurKurzContainer ist ein "löchriger" Behälter für Objekte.
* Jedes Objekt wird nach Ablauf seiner Lebensdauer entsorgt.
*
* Die Lebensdauer ist einheitlich für den gesamten Container,
* jeweils ab einem Zeitpunkt während des Einfügens gemessen.
*
* Es gibt nur zwei öffentliche Methoden: insert()
* fügt ein neues Objekt hinzu, wenn es nicht schon
* enthalten war, size() ermittelt, für wieviele Objekte
* die Lebensdauer noch nicht abgelaufen ist.
*
* Für die Implementation gibt es zwei Performance-Parameter:
* - Die Kapazität
* - Der Vergrößerungsfaktor.
* Die Kapazität bestimmt (teilweise) den Speicherplatzverbrauch,
* das Verhältnis von Kapazität und Zahl tatsächlich enthaltener
* Objekte bestimmt (bei guter Hashfunktion) die Einfügegeschwindigkeit
* (es muss ja zunächst überprüft werden, ob das Objekt schon
* drin ist).
* Wenn dieses Verhältnis den Faktor übersteigt, wird die Kapazität
* erhöht (auf etwas mehr als das doppelte).
*
* Diese Klasse ist nicht thread-safe, muss extern synchronisiert werden,
* wenn sie von mehreren Threads verwendet werden soll.
*
* @author Paul Ebermann
* @version 0.0 (2004-10-05), noch nicht getestet.
*/
class NurKurzContainer
{

/**
* Erstellt einen neuen NurKurzContainer.
*
* @param initialCapacity Anfangskapazität.
* @param faktor Vergrößerungsfaktor
* @param livetime die Lebensdauer (Dauer, des
* Enthaltenseins) von eingefügten Objekten, in ms.
* Die Genauigkeit hängt von der der System-Uhr
* ({@link System#currentTimeMillis} ab.
*/
public NurKurzContainer(int initialCapacity, float faktor, long livetime)
{
assert (faktor > 0);
this.FAKTOR = faktor;
assert (livetime >= 0);
this.LIVETIME = livetime;
tabelle = new Element[initialCapacity];
}

/**
* Erstellt einen neuen NurKurzContainer mit
* angegebener Lebensdauer (in ms) und Standard-Kapazität
* und -Vergrößerungsfaktor.
*/
public NurKurzContainer(long liveTime)
{
this (20, 0.8, liveTime);
}

/**
* Erstellt einen neuen NurKurzContainer mit
* Lebensdauer von 15 Minuten und Standard-Kapazität
* und -Vergrößerungsfaktor.
*/
public NurKurzContainer()
{
this(20, 0.8, 1000*60*15);
}


/**
* Fügt ein neues Objekt hinzu, wenn es nicht bereits
* enthalten ist (was mittels .equals festgestellt wird).
*
* Dies erhöht gewöhnlich die Anzahl der Objekte um
* 1, allerdings können gleichzeitig alte Objekte
* rausgeworfen werden.
*
* @param s das neue Objekt.
* @see Object#equals
* @see Object#hashCode
*/
public void insert(Object s)
{
if (size() >= tabelle.length * FAKTOR)
{
resize();
}

Element neu = new Element(s, System.currentTimeMillis() + LIVETIME);

if ( contains(s, neu.hash))
return; // Objekt schon enthalten, keine Neuaufnahme notwendig.

neu.insertToTab();
neu.appendToList();
anzahl ++;
}


/**
* Ermittelt die Anzahl verschiedener Objekte in diesem
* Container, deren Haltbarkeitsdatum noch nicht abgelaufen
* ist.
*/
public int size()
{
if (erstes == null) // keine Elemente mehr übrig.
return anzahl = 0;

long aktuell = System.currentTimeMillis();

if (erstes.timeout > aktuell)
return anzahl;

while (erstes != null && erstes.timeout <= aktuell)
{
// aus Hashtabelle löschen
if (erstes.vorherNachHash != null)
erstes.vorherNachHash.nächstesNachHash = null;
else
tabelle[erstes.hash] = null;
// aus Liste löschen.
erstes = erstes.nächsterNachTimeout;
anzahl --;
}
if (erstes == null) // alle Elemente entsorgt
letztes = null; // ==> es gibt kein letztes mehr.

return anzahl;
}


/********** Implementation ********************/

/** Belegungsgrad, ab dem die Tabelle vergrößert wird. */
private final float FAKTOR;

/** Lebensdauer der Objekte in ms*/
private final long LIVETIME;

/**
* Ein Element der Liste/Hashtabelle
*/
private class Element
{
/**
* Erstellt ein neues Element mit angegebenem Wert und Haltbarkeitsdatum.
*/
Element(Object value, long timeout)
{
this.timout = timeout;
this.value = value;
berechneHash();
}

/**
* Berechnet den Hash neu.
* Dieser ist abhängig von der aktuellen Größe
* der hash-Tabelle und dem hashCode des Wertes.
*/
void berechneHash() {
this.hash = Math.abs(value.hashCode()) % tabelle.length;

}

/** Der Wert. */
Object value;

/** Ein Hash. */
int hash;

/** Das Haltbarkeitsdatum */
long timeout;

/** Verkettete Liste aller Elemente */
Element nächsterNachTimeout;

/** Doppelt verkettete List der Elemente
* mit gleichem hash.
* nächsteNachHash ist für den Test notwendig, ob ein Objekt schon da ist.
* vorherNachHash ist zum effektiven Entsorten von alten Objekten
* gut (es wird immer nur das letzte Element einer Liste entfernt).
*/
Element
nächsterNachHash,
vorherNachHash:

/**
* Fügt das Element in die Hashtabelle ein
* (als erstes in die doppelt verkettete Liste
* der Elemente mit gleichem hash.)
*/
void insertToTab()
{
vorherNachHash = null;
nächsterNachHash = tabelle[hash];
if (nächsterNachHash != null)
nächsterNachHash.vorherNachHash = this;
tabelle[hash] = this;
}

/**
* Hängt das Element an das Ende der verketteten Liste
* aller Elemente des Containers an.
*/
private void appendToList()
{
if (letztes != null)
{
letztes.nächsterNachZeit = neu;
}

letztes = neu;

if (erstes == null) // vorher noch kein erstes Element vorhanden
{
erstes = neu;
}
}
} // class Element

/** Hash-Tabelle aller Elemente, Elemente mit
* gleichem Hash (als doppelt verkettete Liste)
* sind umgekehrt nach Timeoutzeit (bzw. Einfügezeit)
* sortiert.
*/
private Element[] tabelle;

/** verkettete Liste aller Elemente, nach Timeout-Zeit
* (bzw. Einfügezeit) sortiert
*/
private Element erstes;
private Element letztes;

/** aktuelle Anzahl der Objekte. */
private int anzahl;

/**
* Sucht in der Hashtabelle, ob ein Objekt schon
* vorhanden ist.
* @param s das zu suchende Objekt
* @param hash der hash des Objektes (entsprechend Element#berechneHash)
*
* @return true, falls es gefunden wurde, sonst false.
*/
private boolean contains(Object s, int hash)
{
for (Element suche = tabelle[hash];
suche != null;
suche = suche.nächsterNachHash)
{
if (suche.value.equals(s))
return true;
}
return false;
}

/**
* Erstellt die Hash-Tabelle mit einer neuen Größe (etwas
* mehr als das doppelte der alten) neu.
*/
private void resize()
{
// neue Tabelle
tabelle = new Element[tabelle.length * 2 + 3];

/// alle Elemente in richtiger Reihenfolge einsortieren
for (Element aktuell = erstes;
aktuell != null;
aktuell = aktuell.nächstesNachTimeout)
{
aktuell.berechneHash();
aktuell.insertToTab();
}
}

}
---


Grüße
Paul
--
Eine Signatur sollte mit "-- " abgetrennt werden,
wobei OjE meist das " " verschluckt. Eine nicht
korrekt abgetrennte Signatur ist keine Signatur ...
Oliver S.
2004-10-03 18:08:41 UTC
Permalink
Post by Olaf Eilers
Interessehalber, wie würdet Ihr eine HashMap implementieren, deren
Werte zeitabhängig sind, also z.B. Werte, die älter als 15 Minuten
sind, fliegen raus?
Mit einer LinkedHashMap.
Sven Köhler
2004-10-03 18:57:46 UTC
Permalink
Post by Olaf Eilers
Interessehalber, wie würdet Ihr eine HashMap implementieren, deren Werte
zeitabhängig sind, also z.B. Werte, die älter als 15 Minuten sind,
fliegen raus?
Ich würde eine LinkedList (selbstgebastelt) hinzuziehen, da man dort
einfach Elemente mitten rausnehmen kann, und ans Ende setzen kann.
Mit den Java-mitgelieferten Klassen geht das freilich nicht.

Ich würde dann jedesmal wenn ein Element in der HashMap gebraucht wird,
das Element in der Liste an den Anfang setzen, den Zeitstempel updaten.

Ein netter nebeneffekt ist, dass die Zeitstempel in der Liste sortiert
sind. D.h. ich kann sehr einfach rausfinden, welche Elemente 15min. alt
sind.

Im großen und ganzen geht das mit O(1) Zusatzaufwand gegenüber der HashMap.
Achim Peters
2004-10-03 20:00:26 UTC
Permalink
Post by Olaf Eilers
Interessehalber, wie würdet Ihr eine HashMap implementieren, deren Werte
zeitabhängig sind, also z.B. Werte, die älter als 15 Minuten sind,
fliegen raus?
Benötigst Du mehr als

public class Cache

private HashMap timedMap = new HashMap();

public Cache() {}

static class TimedValue {
long inserted;
Object value;
TimedValue(long inserted, Object value) {
this.inserted = inserted;
this.value = value;
}
}

public void put(Object key, Object value) {
timedMap.put(key, new TimedValue(System.currentTimeMillis(), value));
}

public Object get(Object key) {
TimedValue timedValue = (TimedValue)timedMap.get(key);
if (timedValue == null)
return null;
if (timedValue.inserted < System.currentTimeMillis() - 15*60*1000) {
timedMap.remove(key);
return null;
}
else
return timedValue.value;
}
}

plus ggf. noch contains() analog?

Bye
Achim
Wanja Gayk
2004-10-03 20:31:00 UTC
Permalink
Achim Peters said...
Post by Achim Peters
Post by Olaf Eilers
Interessehalber, wie würdet Ihr eine HashMap implementieren, deren Werte
zeitabhängig sind, also z.B. Werte, die älter als 15 Minuten sind,
fliegen raus?
Benötigst Du mehr als
[Sourcecode gesnippt]

Verflucht.. ich sollte eine Thread besser demnächst zuende lesen, bevor
ich ein reply mache... alles umsonst geschrieben, der Code war ja nahezu
identisch.

(Naja, zumindest war's ein Grund gegen Softwarepatente..)

Gruß,
-Wanja-
--
"Gewisse Schriftsteller sagen von ihren Werken immer: 'Mein Buch, mein
Kommentar, meine Geschichte'. [..] Es wäre besser, wenn sie sagten:
'unser Buch, unser Kommentar, unsere Geschichte'; wenn man bedenkt, dass
das Gute darin mehr von anderen ist als von ihnen." [Blaise Pascal]
Achim Peters
2004-10-04 19:57:09 UTC
Permalink
Post by Wanja Gayk
Achim Peters said...
Post by Achim Peters
Post by Olaf Eilers
Interessehalber, wie würdet Ihr eine HashMap implementieren, deren Werte
zeitabhängig sind, also z.B. Werte, die älter als 15 Minuten sind,
fliegen raus?
Benötigst Du mehr als
[Sourcecode gesnippt]
Verflucht.. ich sollte eine Thread besser demnächst zuende lesen, bevor
ich ein reply mache... alles umsonst geschrieben, der Code war ja nahezu
identisch.
:-) Ja, erstaunlich. Wobei mir Dein Weg, die Expiration-Time schon vorab
festzulegen, besser gefällt, wenn sie denn wirklich fix ist.
Post by Wanja Gayk
(Naja, zumindest war's ein Grund gegen Softwarepatente..)
:-) Yep. Allerdings wenn ich mir die üblichen Argumente gegen
Softwarepatente so angucke, passen die IMHO auch gegen normale
(Hardware-)Patente. Abschreiben darf man natürlich schon aus anderen
Gründen nicht, aber zur (beinahe) gleichen Zeit oder später die gleiche
Idee haben (und sie auswerten), darf man auch nicht.

Bye
Achim
Wanja Gayk
2004-10-04 20:31:37 UTC
Permalink
Achim Peters said...
Post by Achim Peters
Post by Wanja Gayk
(Naja, zumindest war's ein Grund gegen Softwarepatente..)
:-) Yep. Allerdings wenn ich mir die üblichen Argumente gegen
Softwarepatente so angucke, passen die IMHO auch gegen normale
(Hardware-)Patente.
Habe ich schon bemerkt, dass ich gänzlich gegen Patente bin?

Gruß,
-Wanja-
--
"Gewisse Schriftsteller sagen von ihren Werken immer: 'Mein Buch, mein
Kommentar, meine Geschichte'. [..] Es wäre besser, wenn sie sagten:
'unser Buch, unser Kommentar, unsere Geschichte'; wenn man bedenkt, dass
das Gute darin mehr von anderen ist als von ihnen." [Blaise Pascal]
Wanja Gayk
2004-10-03 20:25:59 UTC
Permalink
Olaf Eilers said...
Post by Olaf Eilers
Interessehalber, wie würdet Ihr eine HashMap implementieren, deren Werte
zeitabhängig sind, also z.B. Werte, die älter als 15 Minuten sind,
fliegen raus?
ich würde jedes Objekt mit einem Zeitstempel versehen und beim
herausholen aus der Map schauen, ob der Eintrag noch gültig ist, in etwa
so:

public TimeoutHashMap{

private final hashMap map = new HashMap();

public void put(final Object key, final Object value){
map.put(key, new TimestampWrapper(value));
}

public Object get(final Object key){
final TimestampWrapper w = (TimestampWrapper)map.get(key);
if(w.expirationTimeMillis > System.currentTimeMillis()){
map.remove(key);
return null;
}else{
return w.object;
}
}

private class TimestampWrapper{
public final long expirationTimeMillis ;
public final Object object;
public TimestampWrapper(Object object){
this.object=object;
expirationTimeMillis=System.currentTimeMillis()+900000;
}
}
}


Interessant wird es bei den Methoden entrySet(), keySet(), values(),
size() und isEmpty() aus dem Map-Interface.
Da musst du im Zweifel alle Objekte einmal durchtesten, was relativ
langsam werden könnte.

Wenn's dir aber nur drum geht den Speicherverbrauch besser zu
kontrollieren, versuch es doch mal mit einer WeakHashMap

Gruß,
-Wanja-
--
"Gewisse Schriftsteller sagen von ihren Werken immer: 'Mein Buch, mein
Kommentar, meine Geschichte'. [..] Es wäre besser, wenn sie sagten:
'unser Buch, unser Kommentar, unsere Geschichte'; wenn man bedenkt, dass
das Gute darin mehr von anderen ist als von ihnen." [Blaise Pascal]
Eric Bodden
2004-10-03 21:13:46 UTC
Permalink
Elegant, aber eventuell wenig effizient, wäre es auch, jedes eingefügt
Objekt als Thread zu starten und 15 Minuten schlafenzulegen. Durch einen
Rücklink auf das HashSet löscht sich das Objekt dann nach 15 Minuten selbst
;-)

Ich hab leider keine Ahnung, wie sehr sich "schlafende" Threads auf die
Performanz auswirken. Weiß da jemand mehr?

Eric
--
Eric Bodden, ICQ: 12656220, http://www.bodden.de, PGP: BB465582
Active Desktop Wallpaper Changer: That's what it is...
http://bodden.de/projects/wpchanger/
Sven Köhler
2004-10-03 22:00:54 UTC
Permalink
Post by Eric Bodden
Ich hab leider keine Ahnung, wie sehr sich "schlafende" Threads auf die
Performanz auswirken. Weiß da jemand mehr?
hoffentlich gar nicht, denn Sie brauchen quasi vom Scheduler des OS
nicht mehr berücksichtigt werden und können erstmal beiseite gelegt
werden, bis deren Zeit wieder gekommen ist.
Eric Bodden
2004-10-04 06:27:34 UTC
Permalink
Post by Sven Köhler
Post by Eric Bodden
Ich hab leider keine Ahnung, wie sehr sich "schlafende" Threads auf die
Performanz auswirken. Weiß da jemand mehr?
hoffentlich gar nicht, denn Sie brauchen quasi vom Scheduler des OS
nicht mehr berücksichtigt werden und können erstmal beiseite gelegt
werden, bis deren Zeit wieder gekommen ist.
Hmmm danke fürt die Antwort. Wieder was gelernt. Ja dann wäre das doch echt
ne gute Lösung im objektorientierten Sinne...

Happy Coding!

Eric
--
Eric Bodden, ICQ: 12656220, http://www.bodden.de, PGP: BB465582
Arithmetic Coding - educational example code and more
http://ac.bodden.de/
Sven Köhler
2004-10-04 12:02:46 UTC
Permalink
Post by Eric Bodden
Post by Sven Köhler
Post by Eric Bodden
Ich hab leider keine Ahnung, wie sehr sich "schlafende" Threads auf die
Performanz auswirken. Weiß da jemand mehr?
hoffentlich gar nicht, denn Sie brauchen quasi vom Scheduler des OS
nicht mehr berücksichtigt werden und können erstmal beiseite gelegt
werden, bis deren Zeit wieder gekommen ist.
Hmmm danke fürt die Antwort. Wieder was gelernt. Ja dann wäre das doch echt
ne gute Lösung im objektorientierten Sinne...
Nein, eigentlich nicht. Jeden Eintrag als Thread, das ist overkill.
Außerdem dauert es lange, ein Thread zu starten, und es übervordert
irgentwann die Resourcen deines Rechners, oder du stößt an das
Prozess-Limit deines Users.

Ein "Rausschmeißer-Thread" wäre noch OK, aber es eines pro Instanz der
Datenstruktur wäre meiner Meinung nach ebenfalls zuviel.
Michael Rauscher
2004-10-04 12:24:44 UTC
Permalink
Hi Eric,
Post by Eric Bodden
Post by Sven Köhler
Post by Eric Bodden
Ich hab leider keine Ahnung, wie sehr sich "schlafende" Threads auf die
Performanz auswirken. Weiß da jemand mehr?
hoffentlich gar nicht, denn Sie brauchen quasi vom Scheduler des OS
nicht mehr berücksichtigt werden und können erstmal beiseite gelegt
werden, bis deren Zeit wieder gekommen ist.
Hmmm danke fürt die Antwort. Wieder was gelernt. Ja dann wäre das doch echt
ne gute Lösung im objektorientierten Sinne...
Wie kommst Du darauf?

Nehmen wir mal an, wir hätten eine Klasse Eintrag. Diese als Thread zu
modellieren kommt aus Gründen der Kohäsion nicht in Frage: der innere,
logische Zusammenhang der Klasse Eintrag würde zu schwach werden.

Also trennt man den Thread heraus, man könnte sich eine
ThreadWrapper-Klasse basteln. Die Liste bekommt dann nicht mehr
Eintrag-Objekte sondern ThreadWrapper-Objekte.

Nun ist eine Liste aber wenigstens eine Aggregation seiner Elemente,
d.h. zwischen der Liste und den ThreadWrapper-Objekten besteht eine
Ganzes-Teile-Beziehung. Teile sollten aber nicht wissen, wer ihr Ganzes
ist und ob es überhaupt ein Ganzes gibt, damit die Kopplung nicht zu
stark wird und die Teile einfach herausgelöst werden können.

Jetzt kann man die Liste vom ThreadWrapper entkoppeln, indem man
ThreadWrapper gegen ein neues Interface arbeiten lässt, um am Ende
festzustellen, dass man

- für jeden Eintrag ein Eintrag-Objekt und eine ThreadWrapper-Instanz
braucht,

- die Arbeit von allen ThreadWrapper-Instanzen auch von einem einzigen
Objekt erledigt werden könnte, womit man

- die ThreadWrapper gar nicht braucht
Post by Eric Bodden
Happy Coding!
Eric
Grüße
Michael
Stefan Matthias Aust
2004-10-04 12:48:22 UTC
Permalink
Post by Michael Rauscher
Post by Eric Bodden
Hmmm danke fürt die Antwort. Wieder was gelernt. Ja dann wäre das doch
echt ne gute Lösung im objektorientierten Sinne...
Wie kommst Du darauf?
Doch, das wäre im OO-Sinne eine gute Lösung, da sie dem Actor-Prinzip
und der eigentlichten OO-Idee der frühen 80er entsprechen würde: Objekte
als aktive Prozesse. Sie ist nur in Java wahrscheinlich nicht
unmittelbar praktikabel umsetzbar.
--
Stefan Matthias Aust
Michael Rauscher
2004-10-04 18:24:45 UTC
Permalink
Post by Stefan Matthias Aust
Post by Michael Rauscher
Post by Eric Bodden
Hmmm danke fürt die Antwort. Wieder was gelernt. Ja dann wäre das
doch echt ne gute Lösung im objektorientierten Sinne...
Wie kommst Du darauf?
Doch, das wäre im OO-Sinne eine gute Lösung, da sie dem Actor-Prinzip
und der eigentlichten OO-Idee der frühen 80er entsprechen würde: Objekte
als aktive Prozesse. Sie ist nur in Java wahrscheinlich nicht
unmittelbar praktikabel umsetzbar.
Wahrscheinlich hätte ich meine Frage anders formulieren sollen.
Unabhängig davon, ob das Objekt nun in Form eines "aktiven Prozesses"
vorliegt oder nicht: kann es Aufgabe eines Objekts (z. B. ein Kunde)
sein, das "zufällig" zu einer Liste aggregiert wird (von der das Objekt
nichts weiß), sich selbst aus dieser Liste zu entfernen?

Gruß
Michael
Eric Bodden
2004-10-04 18:10:31 UTC
Permalink
Post by Michael Rauscher
Wie kommst Du darauf?
Na das will ich Dir gerne erklären: Aus persönlicher Erfahrung. Nehmen wir
z.B. unseren WG-Kühlschrank.

Denn da regt es mich schon seit jeher auf, daß ich anscheinend in
regelmäßigen Abständen (wie ein TimerTask) eben diesen Kühlschrank nach
abgelaufenen Lebensmitteln durchforsten muß, um mich selbst vor eventuellen
Folgeschäden zu schützen. Genauso unbequem finde ich die "lazy" Variante 2,
die besagt, daß ich jedesmal, wenn ich etwas herausnehme, auf das
Haltbarkeitsdatum schaue.
Perfekt (naja nicht ganz, aber besser) wäre doch eine Welt, in der sich die
Lebensmittel selber nach Ablauf ihrer Haltbarkeit in's Nirvana schicken
würden. Ich möchte mal behaupten, damit könnte man nicht wenig Geld
verdienen. Schließlich bräuchte man nicht mal mehr ein Haltbarkeitsdatum!

In diesem Sinne, denke ich, sollte man also als guter Software Architekt
ruhig an den richtigen Stellen mal von der Realität abstrahieren.

Was Effizienz angeht, so haben meine Vorredner allerdings recht. Ich hab
mich schlau gemacht und es ist zwar so, daß thread, die idlen eigentlich
keine Cycles verbrauchen, dafür aber einen enormen Footprint haben (wegen
eigenem Laufzeitstack etc.) und daher bei den meissten Benchmarks bei
einigen hundert bis wenigen tausend Stück Schluß ist (wen's interessiert,
der schaue sich VolanoMark an). Als generelle Lösung ist mein Vorschlag
also nicht zu empfehlen. Jedoch bestehte ich auf der Esthetik dieses
Ansatzes ;-)

So far...

Eric
--
Eric Bodden, ICQ: 12656220, http://www.bodden.de, PGP: BB465582
Arithmetic Coding - educational example code and more
http://ac.bodden.de/
Michael Rauscher
2004-10-04 18:33:13 UTC
Permalink
Post by Eric Bodden
Post by Michael Rauscher
Wie kommst Du darauf?
Na das will ich Dir gerne erklären: Aus persönlicher Erfahrung. Nehmen wir
z.B. unseren WG-Kühlschrank.
[...]
Post by Eric Bodden
Perfekt (naja nicht ganz, aber besser) wäre doch eine Welt, in der sich die
Lebensmittel selber nach Ablauf ihrer Haltbarkeit in's Nirvana schicken
würden. Ich möchte mal behaupten, damit könnte man nicht wenig Geld
verdienen. Schließlich bräuchte man nicht mal mehr ein Haltbarkeitsdatum!
Ja, da hast Du recht. Allerdings sehe ich hier einen entscheidenden
Unterschied: Lebensmittel, die man im Kühlschrank aufbewahren sollte,
"wissen" dann aber auch, dass sie in einem Kühlschrank stehen sollten.

Nur weil ich ein beliebiges Objekt auf eine Liste setzen kann, gehört es
nicht zur Logik des Objekts, zu wissen, ob man vielleicht und falls ja,
auf welcher Liste steht.
Post by Eric Bodden
In diesem Sinne, denke ich, sollte man also als guter Software Architekt
ruhig an den richtigen Stellen mal von der Realität abstrahieren.
Man sollte eigentlich immer von der Realität abstrahieren - sonst wirds
hart :-)
Post by Eric Bodden
Was Effizienz angeht, so haben meine Vorredner allerdings recht. Ich hab
mich schlau gemacht und es ist zwar so, daß thread, die idlen eigentlich
keine Cycles verbrauchen, dafür aber einen enormen Footprint haben (wegen
eigenem Laufzeitstack etc.) und daher bei den meissten Benchmarks bei
einigen hundert bis wenigen tausend Stück Schluß ist (wen's interessiert,
der schaue sich VolanoMark an). Als generelle Lösung ist mein Vorschlag
also nicht zu empfehlen. Jedoch bestehte ich auf der Esthetik dieses
Ansatzes ;-)
Auch wenn ich mich mit Deinem Ansatz nicht anfreunden kann: sie sei Dir
gegönnt :-)
Post by Eric Bodden
So far...
Eric
Gruß
Michael
Eric Bodden
2004-10-04 18:48:39 UTC
Permalink
Post by Michael Rauscher
Ja, da hast Du recht. Allerdings sehe ich hier einen entscheidenden
Unterschied: Lebensmittel, die man im Kühlschrank aufbewahren sollte,
"wissen" dann aber auch, dass sie in einem Kühlschrank stehen sollten.
Nur weil ich ein beliebiges Objekt auf eine Liste setzen kann, gehört es
nicht zur Logik des Objekts, zu wissen, ob man vielleicht und falls ja,
auf welcher Liste steht.
Da hast Du recht. Deswegen würde ich sie dann auch mit einem "Decorator"
versehen, der weiß, wie das geht ;-) Quasi eine Verpackung, die immer noch
aussieht, wie das originale Lebensmittel, jedoch nun auch die fähigkeit
besitzt, sich selbst mit eben diesem zu entsorgen.

Eric
--
Eric Bodden, ICQ: 12656220, http://www.bodden.de, PGP: BB465582
Arithmetische Kodierung - eine umfassende Einführung
http://bodden.de/studies/publications/pub_ac_de/
Michael Rauscher
2004-10-04 18:49:00 UTC
Permalink
Post by Eric Bodden
Post by Michael Rauscher
Ja, da hast Du recht. Allerdings sehe ich hier einen entscheidenden
Unterschied: Lebensmittel, die man im Kühlschrank aufbewahren sollte,
"wissen" dann aber auch, dass sie in einem Kühlschrank stehen sollten.
Nur weil ich ein beliebiges Objekt auf eine Liste setzen kann, gehört es
nicht zur Logik des Objekts, zu wissen, ob man vielleicht und falls ja,
auf welcher Liste steht.
Da hast Du recht. Deswegen würde ich sie dann auch mit einem "Decorator"
versehen, der weiß, wie das geht ;-) Quasi eine Verpackung, die immer noch
aussieht, wie das originale Lebensmittel, jedoch nun auch die fähigkeit
besitzt, sich selbst mit eben diesem zu entsorgen.
Na, dann kommen wir uns doch näher: Thread-Geschichten aus der Klasse
ziehen ;-) An den Decorator hatte ich noch gar nicht gedacht. Damit
wären dann die doppelten Objekte weg, der Decorator macht, was er tun
soll - saubere Sache.

Gruß
Michael
Martin Metz
2004-10-05 06:46:47 UTC
Permalink
Post by Eric Bodden
Post by Michael Rauscher
Wie kommst Du darauf?
Was Effizienz angeht, so haben meine Vorredner allerdings recht. Ich hab
mich schlau gemacht und es ist zwar so, daß thread, die idlen eigentlich
keine Cycles verbrauchen, dafür aber einen enormen Footprint haben (wegen
eigenem Laufzeitstack etc.) und daher bei den meissten Benchmarks bei
einigen hundert bis wenigen tausend Stück Schluß ist (wen's interessiert,
der schaue sich VolanoMark an). Als generelle Lösung ist mein Vorschlag
also nicht zu empfehlen. Jedoch bestehte ich auf der Esthetik dieses
Ansatzes ;-)
Na dann verlange doch beides! ;-)

Beispiel: Die Element-Klasse hat einen eigenen privaten und statischen
Thread. Somit teilen sich alle Element-Objekte einen Thread (egal ob es
5, 100 oder 10^20 davon gibt) und schonen somit Resourcen. Und trotzdem
agieren sie von außen her autark (tragen sich selbst in das private
Thread-handling ein und entfernen sich selbst).
Natürlich sind noch weitere Optimierungen empfehlenswert, wenn es
wirklich viele Elemente sind. Evtl. sollten sie beim Einfügen die
Elemente in eine Listen hinten anhängen. Der Thread muß dann diese Liste
nur noch vom Anfang an durchsuchen, bis sie leer ist oder das erste
Element gefunden wird, das NICHT zu löschen ist.
--
Gruesse,

Martin Metz
Eric Bodden
2004-10-05 16:58:34 UTC
Permalink
Post by Martin Metz
Na dann verlange doch beides! ;-)
[...]
Joa, also das ist dann mal wirklich sexy ;-)

Eric
--
Eric Bodden, ICQ: 12656220, http://www.bodden.de, PGP: BB465582
Arithmetische Kodierung - eine umfassende Einführung
http://bodden.de/studies/publications/pub_ac_de/
Michael Borgwardt
2004-10-04 21:17:08 UTC
Permalink
Post by Sven Köhler
Post by Eric Bodden
Ich hab leider keine Ahnung, wie sehr sich "schlafende" Threads auf die
Performanz auswirken. Weiß da jemand mehr?
hoffentlich gar nicht, denn Sie brauchen quasi vom Scheduler des OS
nicht mehr berücksichtigt werden und können erstmal beiseite gelegt
werden, bis deren Zeit wieder gekommen ist.
Da melde ich aber mal ganz massive Bedenken an!

Auch ein wartender Thread kann, je nach Implementation des Schedulers, diesen
Arbeit kosten - IIRC war der von Linux bis 2.4 bei O(n) in der Zahl der
Prozesse (Threads sind ja für Linux Prozesse). Ganz davon abgesehen, daß
auch das Überprüfen, ob die Wartezeit abgelaufen ist, vermutlich für jeden
Thread extra stattfinden würde, und das bei jedem Tick der Systemuhr.

Der absolute Killer ist aber der Stack - davon kriegt jeder Java-Thread
per defaul ein paar hundert KB, und auch wenn man das im Konstruktor
runtersetzen kann dürfte die Mindestgröße (OS-abhänging) plus Overhead
immer noch mindestens einige KB betragen.

Nee, das ist eine absolute Schnapsidee. Mag sein daß es auf manchen
JVMs und Betriebssystemen praktikabel wäre, aber das dürfte eher die
Ausnahme sein.
Sven Köhler
2004-10-04 21:43:26 UTC
Permalink
Post by Michael Borgwardt
Post by Sven Köhler
Post by Eric Bodden
Ich hab leider keine Ahnung, wie sehr sich "schlafende" Threads auf die
Performanz auswirken. Weiß da jemand mehr?
hoffentlich gar nicht, denn Sie brauchen quasi vom Scheduler des OS
nicht mehr berücksichtigt werden und können erstmal beiseite gelegt
werden, bis deren Zeit wieder gekommen ist.
Da melde ich aber mal ganz massive Bedenken an!
Auch ein wartender Thread kann, je nach Implementation des Schedulers, diesen
Arbeit kosten - IIRC war der von Linux bis 2.4 bei O(n) in der Zahl der
Prozesse (Threads sind ja für Linux Prozesse). Ganz davon abgesehen, daß
auch das Überprüfen, ob die Wartezeit abgelaufen ist, vermutlich für jeden
Thread extra stattfinden würde, und das bei jedem Tick der Systemuhr.
Der Scheduler sollte die schlafenden Thread in eine PriorityQueue
auslagern. Nach jeder Runde wird dann überprüft, welche Threads wieder
anlaufen dürfen. Diese Überprüfung ist aber im Best-Case nur ein
vergleich, da ja in der PriotityQueue der niedrigste Zeitstempel zuerst
kommt. kA ob das irgentein Scheduler in freier Wildbahn so macht, aber
es wäre Ratsam.

Allerdings wird sich bei diesem Scenrio die Anzahl der wartenden Thread
auf die Zeit zum Einfügen/Löschen von Einträgen in der PriotityQueue
aus, drücke also doch - wenn auch nur geringfügig - auf die Performance.
Post by Michael Borgwardt
Nee, das ist eine absolute Schnapsidee. Mag sein daß es auf manchen
JVMs und Betriebssystemen praktikabel wäre, aber das dürfte eher die
Ausnahme sein.
Jap. Stimmt.
Marc Peter
2004-10-05 09:12:31 UTC
Permalink
Post by Michael Borgwardt
Post by Sven Köhler
Post by Eric Bodden
Ich hab leider keine Ahnung, wie sehr sich "schlafende" Threads auf die
Performanz auswirken. Weiß da jemand mehr?
hoffentlich gar nicht, denn Sie brauchen quasi vom Scheduler des OS
nicht mehr berücksichtigt werden und können erstmal beiseite gelegt
werden, bis deren Zeit wieder gekommen ist.
Da melde ich aber mal ganz massive Bedenken an!
Mach nur. Bedenken kann man ja mit Argumenten zerstreuen ;)
Post by Michael Borgwardt
Auch ein wartender Thread kann, je nach Implementation des Schedulers, diesen
Arbeit kosten - IIRC war der von Linux bis 2.4 bei O(n) in der Zahl der
Prozesse (Threads sind ja für Linux Prozesse).
Den 2.4'er Linux-Kernel lasse ich nicht als Beispiel einer Scheduler-
Implementierung gelten. Ich bin aus allen Wolken gefallen, als ich
mitgekriegt habe, dass da eine lineare Liste abgesucht wird, um den
nächsten zu aktivierenden Thread zu finden.

Aber in diesem Fall (Linux Kernel bis 2.4) sollte man die Anzahl von
Prozessen wirklich gering halten. Der casus knacksus ist hier nur:
Bildet die Java-VM wirklich Threads auf Prozesse ab? Sie müsste es
nicht wirklich tun...
Post by Michael Borgwardt
Ganz davon abgesehen, daß
auch das Überprüfen, ob die Wartezeit abgelaufen ist, vermutlich für jeden
Thread extra stattfinden würde, und das bei jedem Tick der Systemuhr.
Nein.

man priority queue / man heap
[Element einfügen = O(log n), Kleinstes Element finden = O(1), Element
entfernen = O(log n)]
Post by Michael Borgwardt
Der absolute Killer ist aber der Stack - davon kriegt jeder Java-Thread
per defaul ein paar hundert KB, und auch wenn man das im Konstruktor
runtersetzen kann dürfte die Mindestgröße (OS-abhänging) plus Overhead
immer noch mindestens einige KB betragen.
Nein. Der Stack ist völlig unkritisch. Er nutzt nur dann physische
Speicher-Pages, wenn sie auch gebraucht werden. Sonst sind die Page-
Table-Einträge so gesetzt, dass beim Zugriff eine Exception (Page-Fault)
geworfen wird, welche vom Exception-Handler des OS benutzt wird, um
neuen Stack-Speicher zur Verfügung zu stellen.
Post by Michael Borgwardt
Nee, das ist eine absolute Schnapsidee. Mag sein daß es auf manchen
JVMs und Betriebssystemen praktikabel wäre, aber das dürfte eher die
Ausnahme sein.
Ich gebe zu, dass eine VM auf dem Lego Mindstorms damit ihre Probleme
hätte, aber wir reden hier von "richtigen" Umgebungen, oder?

bis dann
Marc
Michael Borgwardt
2004-10-05 09:33:54 UTC
Permalink
Post by Marc Peter
Post by Michael Borgwardt
Auch ein wartender Thread kann, je nach Implementation des Schedulers, diesen
Arbeit kosten - IIRC war der von Linux bis 2.4 bei O(n) in der Zahl der
Prozesse (Threads sind ja für Linux Prozesse).
Den 2.4'er Linux-Kernel lasse ich nicht als Beispiel einer Scheduler-
Implementierung gelten.
Das wird diejenigen, deren Server darauf läuft, herzlich wenig interessieren.
Post by Marc Peter
Aber in diesem Fall (Linux Kernel bis 2.4) sollte man die Anzahl von
Prozessen wirklich gering halten.
man plattformunabhängigkeit
Post by Marc Peter
Bildet die Java-VM wirklich Threads auf Prozesse ab? Sie müsste es
nicht wirklich tun...
Sie tut aber.
Post by Marc Peter
Post by Michael Borgwardt
Ganz davon abgesehen, daß
auch das Überprüfen, ob die Wartezeit abgelaufen ist, vermutlich für jeden
Thread extra stattfinden würde, und das bei jedem Tick der Systemuhr.
Nein.
man priority queue / man heap
Ist mir bestens bekannt, aber auch das ist ein "müßte eigentlich", was,
wie wir eins weiter oben gesehen haben, herzlich wenig damit zu tun hat,
was wirklich getan wird, und was man daher voraussetzen kann.
Post by Marc Peter
Post by Michael Borgwardt
Der absolute Killer ist aber der Stack - davon kriegt jeder Java-Thread
per defaul ein paar hundert KB, und auch wenn man das im Konstruktor
runtersetzen kann dürfte die Mindestgröße (OS-abhänging) plus Overhead
immer noch mindestens einige KB betragen.
Nein. Der Stack ist völlig unkritisch. Er nutzt nur dann physische
Speicher-Pages, wenn sie auch gebraucht werden. Sonst sind die Page-
Table-Einträge so gesetzt, dass beim Zugriff eine Exception (Page-Fault)
geworfen wird, welche vom Exception-Handler des OS benutzt wird, um
neuen Stack-Speicher zur Verfügung zu stellen.
Ist das auch wieder ein "müßte eigentlich"? Legst Du deine Hand ins Feuer
dafür daß alle gebräuchlichen OSe das so tun?

Ganz abgesehen davon daß selbst bei dieser Implementation eher früher
als später der Adreßraum einer 32bit-Maschine an seine Grenzen stößt.
Post by Marc Peter
Post by Michael Borgwardt
Nee, das ist eine absolute Schnapsidee. Mag sein daß es auf manchen
JVMs und Betriebssystemen praktikabel wäre, aber das dürfte eher die
Ausnahme sein.
Ich gebe zu, dass eine VM auf dem Lego Mindstorms damit ihre Probleme
hätte, aber wir reden hier von "richtigen" Umgebungen, oder?
Ja, *ich* rede von richtigen Umgebungen, wie sie tatsächlich im Einsatz sind,
wie z.B. Linux 2.4.

Du redest von in allen Details perfekt skalierenden OSen. Mag sogar sein
daß auch einige reale OSe Deinen Anforderungen genügen, das ist aber kein
ausreichender Grund, sich durch fragwürdige Programmiertechniken die
Plattformunabhängigkeit zu zerschießen.
Marc Peter
2004-10-05 15:25:38 UTC
Permalink
Post by Michael Borgwardt
man plattformunabhängigkeit
... und einige andere richtige Einsichten
Es läuft wieder mal darauf hinaus: "Überlege, was schlimmstenfalls
eintreten kann, und gehe davon aus, dass genau das irgendwo passieren
wird. Richte dich darauf ein." Welcome to the real world.
Post by Michael Borgwardt
Post by Marc Peter
man priority queue / man heap
Ist mir bestens bekannt, aber auch das ist ein "müßte eigentlich", was,
wie wir eins weiter oben gesehen haben, herzlich wenig damit zu tun hat,
was wirklich getan wird, und was man daher voraussetzen kann.
Ich hatte das in den falschen Kontext gestellt und nicht beachtet, dass
von einem Thread pro Objekt die Rede war.

Mein Vorschlag wäre gewesen: Ein Thread, der eine priority queue von
Ablaufzeitpunkten mit zugehörigen zu löschenden Objekten verwaltet.

bis dann
Marc
Michael Borgwardt
2004-10-05 15:27:34 UTC
Permalink
Post by Marc Peter
Ich hatte das in den falschen Kontext gestellt und nicht beachtet, dass
von einem Thread pro Objekt die Rede war.
Mein Vorschlag wäre gewesen: Ein Thread, der eine priority queue von
Ablaufzeitpunkten mit zugehörigen zu löschenden Objekten verwaltet.
Ja, so eine Lösung könnte ich auch uneingeschränkt befürworten :)
Stefan Matthias Aust
2004-10-03 22:17:59 UTC
Permalink
Post by Eric Bodden
Ich hab leider keine Ahnung, wie sehr sich "schlafende" Threads auf die
Performanz auswirken. Weiß da jemand mehr?
In Theorie "gar nicht". In der Praxis hoffentlich auch nicht. Problem
könnte sein, wenn die VM dumm und simpel einfach pro Thread einen
OS-Thread nimmt. Dann könnte man zu wenige davon haben.

Eine Sprache wie Io, die hervorhebt multithreading zu unterstützen und
gerade keine OS-Threads benutzt, nimmt für sich in Anspruch, mit
mehreren 10.000 THreads klarzukommen und damit für Actor-style (Actors
sind aktive Objekte, die jeweils in einem eigenen Thread laufen)
programming geeignet zu sein.


bye
--
Stefan Matthias Aust // "Zweifel sind der Ansporn des Denkens..." -U
Olaf Eilers
2004-10-04 12:16:06 UTC
Permalink
Danke für die rege Beteiligung.

Ich habe das jetzt so gelöst, das ich von TimerTask ableite und die
Elemente nach gegebener Zeit rausschmeisse.

Danke und Gruss,
Olaf
Michael Schuerig
2004-10-05 18:20:44 UTC
Permalink
Post by Olaf Eilers
Interessehalber, wie würdet Ihr eine HashMap implementieren, deren
Werte zeitabhängig sind, also z.B. Werte, die älter als 15 Minuten
sind, fliegen raus?
Wie wär's mit einem Hashbelt:

http://www.onjava.com/lpt/a/1343
http://www.onjava.com/lpt/a/1450

Michael
--
Michael Schuerig Airtight arguments have
mailto:***@schuerig.de vacuous conclusions.
http://www.schuerig.de/michael/ --A.O. Rorty, Explaining Emotions
Lesen Sie weiter auf narkive:
Loading...