Cache problem lösung gesucht

[Klaus Berensteiner]

Hallo,

ein Cache ist ja eine optimale Lösung um langsame Festplatten ein wenig flotter zu machen. Was natürlich nicht geht und auch nicht so ist. Aber ein Geschwindigkeitsvorteil wird selbstverständlich bei korrekter implementierung erzielt. Genau das ist mein Problem.

Ich habe eine Anwendung, arbeitet sehr intensiv mit Dateien auf Festplatten (leider keine SSDs), und mit Threads.
Die einzelnen Threads kommunizieren über Shared Memory und mit Signalen.
Also ihr seht es wird natürlich mit GNU/Linux gearbeitet (aus dem Hause RedHat). Momentan ist gar kein Cache implementiert.

Eine Idee, leider gescheitert aus verständlichen Gründen, war es eine Klasse zu erstellen die diese Funktion bereitstellt.

Es wird mit C++ gearbeitet.

Leider klappte es aber nicht so ganz die Threads so zu steuern das das Programm nicht zerschossen wird. Es wurde auch mit Mutexen gearbeitet. Aber dann lief die Anwendung nicht um den erwarteten Geschwindigkeitsgewinn schneller.
Eine Methode der Klasse wurde von einem Thread aufgerufen die den Cache aktualisierte und die geänderten Dateien auf die Festplatte schrieb. Es gab auch nur eine globale Instanz der Klasse. Mit dieser griefen alle Threads auf eine Methode zu die den Cache abfragte nach einer bestimmten Datei. Lag es an der falschen Implementierung dieser Idee? Oder ist diese Idee von vornherein als schlecht abzustempeln?

Welche Möglichkeiten gibt es eine Cachefunktionalität zu implementieren, auch Threadsicher?

Klaus Berensteiner

[Christoph Schnauß]

hallo,

ein Cache ist ja eine optimale Lösung um langsame Festplatten ein wenig flotter zu machen.

Nö, überhaupt nicht. Wenn sich eine HD nun einmal "langsam" dreht, tut sie das auf ziemlich unbeeinflußbare Art. Ob sie auch noch irgendwelche "Caches" enthält, ist der Platte selber absolut egal.

Aber ein Geschwindigkeitsvorteil wird selbstverständlich bei korrekter implementierung erzielt. Genau das ist mein Problem.

Dein Problem ist weit eher, daß du nicht deutlich machen kannst, was du möchtest. Auf deiner Platte kannst du nix "implementieren", nicht einmal ein Staubkorn (falls dir das doch gelingen sollte, wirst du dir danach eine staubkornfreie neue Platte zulegen müssen). Und ein "Geschwindigkeitsvorteil" ist nur so lange ein Vorteil, wie man vergleichen kann, wem gegenüber denn die Geschwindigkeit (übrigens wessen Geschwindigket?) vorteilhafter ist.

Ich habe eine Anwendung, arbeitet sehr intensiv mit Dateien auf Festplatten (leider keine SSDs)

Es gibt so gut wie kein Programm, das nicht mit Dateien arbeiten würde. Und was, bitteschön, ist SSDs?

Die einzelnen Threads kommunizieren über Shared Memory und mit Signalen.

Achso, Threads. Und Kommunikation  mit shared memory. Alles klar. Es kann ja zwischen "shared memory" und deinem "Cache" keinerlei Zusammenhang geben - oder?

Also ihr seht es wird natürlich mit GNU/Linux gearbeitet (aus dem Hause RedHat)

Tut mir leid, das ist nicht zu sehen.

Momentan ist gar kein Cache implementiert.

Wie - wohin denn jetzt? Wenn du keinen Cache hast, aber deine Programme viel shared memory verlangen, klappts nicht? Warum "implementierst" du dann keinen Cache in dein Programm - sehr viele Software hat ja sowas, angefangen bei den Browsern...

Leider klappte es aber nicht so ganz die Threads so zu steuern das das Programm nicht zerschossen wird.

Schade. Du hättest es doch wenigstens einmal zerschießen lassen sollen, um vernünftige logs zu erhalten. Logs sind was Feines ;-)

Eine Methode der Klasse wurde von einem Thread aufgerufen die den Cache aktualisierte

Wie konnte sie das tun, wenn gar kein Cache "implementiert" war?

Lag es an der falschen Implementierung dieser Idee?

Gewiß nicht. Ideen hat man, oder man hat sie nicht; man entwickelt sie, oder entwickelt eben keine; manche Ideen können verfolgt oder unter Strafe gestellt werden. Bisher ist aber noch keinerlei chirurgische Methode bekannt, mit der sich eine Idee auch implementieren ließe. Dem Hörensagen nach gabs mal den Nürnberger Trichter, aber der scheint dir auch irgendwie falsch implementiert worden zu sein.

Oder ist diese Idee von vornherein als schlecht abzustempeln?

Ähm ... welche Idee eigentlich?

Welche Möglichkeiten gibt es eine Cachefunktionalität zu implementieren, auch Threadsicher?

Alle Möglichkeiten, die dein Programm zuläßt. "Funktionalitäten" sind tatsächlich implementierbar. Dazu muß man natürlich wissen, worum es sich konkret handelt, warum und wieviel Cache eventuell benötigt wird, und vor allem muß man wissen, wohin du etwas implementieren möchtest.

Grüße aus Berlin

Christoph S.

[Klaus Berensteiner]

Deine Antwort is ja gut und recht.
Aber entweder nimmst du mich nicht ernst, du hast meinen Thread nicht aufmerksam gelesen, was falsch verstanden oder ich habe mich undeutlich  ausgedrückt.
Aber so schwer kann es doch nicht sein.

Wer kommt auf die kranke Idee das ich an der Festplatte was ändern will? Hoffentlich niemand, dann is ja gut.

Was ich will ist ein Programm zu schreiben. Das einen Cache hat, der halt einfach im Arbeitsspeicher liegt.

Kennst du das Sprichwort man soll ein Rad nicht zweimal erfinden?
Die Arbeit mir 10 Wochen lang den Kopf zu zerbrechen um dann zu einer ähnlichen oder schlechteren Lösung zu kommen wie es schon gibt. Nein, danke darauf kann ich gerne verzichten.

Warum "implementierst" du dann keinen Cache in dein Programm - sehr viele Software hat ja sowas, angefangen bei den Browsern...

Das, ist ja wohl das blödeste was dir einfallen konnte.
GENAU, das will ich ja. Aber ich weiss halt nicht wie ich das am besten mache. Das wollte ich ja wissen.
Aber anstattdessen muss ich mich als Blödmann abstempeln lassen. Vielleicht habe ich mich ja wirklich ein wenig undeutlich ausgedrückt, wer weiss.

Es kann ja zwischen "shared memory" und deinem "Cache" keinerlei Zusammenhang geben - oder?

Darf ich auch erfahren wiso?

Wie konnte sie das tun, wenn gar kein Cache "implementiert" war?
Ähm ... welche Idee eigentlich?

Das war die Idee, das habe ich nun wirklich geschrieben, da gibt es nichts zu rütteln.
Es war eben ein Versuch eine Idee von mir umzusetzen und hat nicht so wirklich funktioniert wie ich mir das vorstellte.

Alle Möglichkeiten, die dein Programm zuläßt. "Funktionalitäten" sind tatsächlich implementierbar. Dazu muß man natürlich wissen, worum es sich konkret handelt, warum und wieviel Cache eventuell benötigt wird, und vor allem muß man wissen, wohin du etwas implementieren möchtest.

Die Cachegröße würde ich dann grade noch verwalten können, ich dachte da so an ein Drittel des zur Verfügung stehenden Arbeitsspeichers.
Wie kann ich diese "Funktionalität" dann implementieren?

Die Theorie das so etwas geht ist auch zu mir durchgedrungen.
Nur wie man so etwas umsetzt nicht.
Oder wie man an so ein Problem herangeht. Ich bräuchte doch auch vll. nur einen Denkanstoss in die Richtige Richtung. z. B. verwende #pragma, damit kannst du tolle caches bauen. (hahaha)

Ich will ja niemanden zu nahe treten oder beleidigen, aber nach dieser Antwort hat bei mir was zu kochen begonnen.

Klaus Berensteiner

[Der Martin]

Hallo Klaus,

ich stimme dir ja durchaus zum, dass Christoph wohl in seiner ihm eigenen brummigen Art offensichtlich nach besten Kräften versucht hat, dich falsch oder gar nicht zu verstehen. Das macht er gern.

Aber ich muss auch zugeben, dass deine Darstellung ziemlich konfus und diffus ist.

ein Cache ist ja eine optimale Lösung um langsame Festplatten ein wenig flotter zu machen. Was natürlich nicht geht und auch nicht so ist. Aber ein Geschwindigkeitsvorteil wird selbstverständlich bei korrekter implementierung erzielt. Genau das ist mein Problem.

Dieser ganze Absatz ist informationsfreies Blabla. Eine schöne Einleitung, aber völlig nutzlos.

Ich habe eine Anwendung, arbeitet sehr intensiv mit Dateien auf Festplatten (leider keine SSDs), und mit Threads.

Äh, Christoph: SSD bedeutet in Gebrauchtwagen-Annoncen "Stahlschiebedach". Aber da wir hier nicht von Autos, sondern eher von Software und Festplatten sprechen, steht es wohl für "Solid State Disk".

Also ihr seht es wird natürlich mit GNU/Linux gearbeitet (aus dem Hause RedHat).

Wie Christoph schon andeutete: Woran sollte man das sehen? Und es spielt auch IMHO keine Rolle. Das Prinzip wäre auf nahezu jedem Betriebssystem dasselbe.

Momentan ist gar kein Cache implementiert.

Doch, da bin ich mir sehr sicher, dass auch Linux schon recht effiziente Cache-Strategien anwendet.

Eine Idee, leider gescheitert aus verständlichen Gründen, war es eine Klasse zu erstellen die diese Funktion bereitstellt.

Abgesehen davon, dass die Gründe alles andere als verständlich sind, sollte man derartige Funktionen auch IMHO nicht auf Applikationsebene duplizieren. Das machen moderne Betriebssysteme schon recht ordentlich.

Es wird mit C++ gearbeitet.

Wo hast du Deutsch gelernt? Solche Passiv-Sätze sind stilistisch sehr schlecht. Besser: "Ich verwende C++".

Leider klappte es aber nicht so ganz die Threads so zu steuern das das Programm nicht zerschossen wird.

Das heißt, dass du noch grobe Fehler oder Schwachstellen im Konzept hast.

Welche Möglichkeiten gibt es eine Cachefunktionalität zu implementieren, auch Threadsicher?

Wichtig ist doch: Es darf nur eine zentrale Funktion geben, die für den Dateizugriff über den Cache zuständig ist. Diese Funktion muss entweder Mechanismen nutzen, die Mehrfachaufrufe (Reentranz) verhindern, etwa Mutex, Semaphore oder ähnliche Verriegelungen, oder sie muss konsequent auf globale Daten verzichten - aber das ist nahezu unmöglich, wenn mehrere Aufrufe letztendlich doch auf eine gemeinsame Ressource, etwa ein- und dieselbe Datei, zugreifen sollen.

Aber so unspezifisch und ungenau wie deine Frage/Problembeschreibung ist, muss leider auch die Antwort ausfallen.

So long,
 Martin