Ringpuffer Bibliothek veröffentlicht

[Rollo62]

Der Thread ist schon etwas älter, aber hatte ich ganz aus den Augen verloren,
und bin gerade durch GetIt nochmal draufgestossen worden dass es den RingBuffer gibt.

Soweit ich das sehe ist dieser nicht threadsafe.
Gibt es da Bestrebungen das mal in diese Richtung zu erweitern ?

Ich benutze RingBuffer um Input/Output Ströme zu entkoppeln, die dann mit unterschiedlichen, variablen Datenraten abgearbeitet werden.
Da wäre threadsafety-ness recht praktisch.

[Uwe Raabe]

Zitat von Rollo62:

Soweit ich das sehe ist dieser nicht threadsafe.
Gibt es da Bestrebungen das mal in diese Richtung zu erweitern ?

Dafür würde ich eine eigene Klasse mit separater Implementierung empfehlen. Ich fände es kontraproduktiv, wenn man die wohl unvermeidlichen Performance-Nachteile auch immer für den non-thread Bereich mitschleppen müsste.

[TurboMagic]

Hallo

der ist vermutlich nicht Thread sicher, jedenfalls war das damals kein Design Ziel.
Was auch noch damit ist: er erlaubt es auch nicht, dass Daten die noch nicht abgerufen
wurden überschrieben werden können.

Sprich: wenn er voll ist un du weitere Daten hinzufügen willst gibt's eine Exception.

Es gab' mal die Überlegung, dafür ein Flag einzubauen und die Klasse so zu erweitern,
dass das wahlweise auch geht, da ich das aber gerade nicht ernsthaft brauche, hab' ich
das noch nicht umgesetzt. Arbeite gerade an anderen Projekten...
...bin aber für Beiträge in diese Richtung und auch in RIchtung einer abgeleiteten Klasse
die Threadsicherheit hinzufügt offen! Lohn ist natürlich die Erwähnung in den Credits!

Grüße
TurboMagic

[himitsu]

Es ist dir ja nicht verboten eine CriticalSection, oder sonstwas hinzuzufügen.

Delphi-Quellcode:

System.TMonitor.Enter(Buffer);
Buffer.Add(irgendwas);
System.TMonitor.Exit(Buffer);

Delphi-Quellcode:

Buffer.Enter;
Buffer.Add(irgendwas);
Buffer.Exit;


type
  TRingbuffer<T> = class(Ringbuffer.TRingbuffer<T>)
    procedure Enter;
    procedure Exit;
  end;

procedure TRingbuffer<T>.Enter;
begin
  System.TMonitor.Enter(Self);
end;

Und vielleicht kommt ja Emba irgendwann in diesem Jahrhundert mal auf die Idee den Schwachsinn bei TMonitor zu reparieren.
> doppelter/missverständlicher Name und umständliche Nutzung (Wenn das eh in TObjekt integriert ist, dann doch bitte richtig)

[TurboMagic]

Hallo,

was wäre, wenn man in die Ringpuffer Klasse so wie sie jetzt ist,
je eine Enter und Leave (Exit als Name würde ich wegen dem Keyword
Exit eher nicht bevorzugen) Methode einbaut, die virtuell, leer und
inline ist aber an allen relevanten Stellen aufgerufen wird.

Wer dann eine Threadsichere Variante will, braucht nur noch von der
bisherigen ableiten und Enter und Leave passend überschreiben.

Wie wäre das?

Grüße
Turbo Magic

[himitsu]

Historisch hab ich sonst ein Leave statt Exit (Exit hier, weil's in TMonitor so heißt)


Implizit ... joar, ich war schreibfaul ... statt du überall vor Ort zu machen,
kann man auch in der Ableitung die Methoden ala Add usw. überdecken/überschreiben und dort das Enter/Exit/Leave rein tun.

Überschreiben (virtual+override) ist besser, falls man zwar die TRingbuffer_Safe<> verwendet, aber die Variable auf TRingbuffer<> stehen bleibt.



Der Vorteil am "Externen" ist, dass man es für ALLE Klassen verwenden kann, ohne Diese erst anpassen zu müssen.



TMonitor hat den Vorteil, dass es multiplatform ist (CriticalSection ist ja Windows) und dass es angeblich schneller sein soll.
Aber der wirkliche Vorteil ist, dass man keine Variable dafür braucht. (OK, die braucht es immernoch, aber sie ist bereits in allen TObject-Nachfahren integriert)

[TurboMagic]

Zitat von himitsu:

Implizit ... joar, ich war schreibfaul ... statt du überall vor Ort zu machen,
kann man auch in der Ableitung die Methoden ala Add usw. überdecken/überschreiben und dort das Enter/Exit/Leave rein tun.

Überschreiben (virtual+override) ist besser, falls man zwar die TRingbuffer_Safe<> verwendet, aber die Variable auf TRingbuffer<> stehen bleibt.

Der Vorteil am "Externen" ist, dass man es für ALLE Klassen verwenden kann, ohne Diese erst anpassen zu müssen.

TMonitor hat den Vorteil, dass es multiplatform ist (CriticalSection ist ja Windows) und dass es angeblich schneller sein soll.
Aber der wirkliche Vorteil ist, dass man keine Variable dafür braucht. (OK, die braucht es immernoch, aber sie ist bereits in allen TObject-Nachfahren integriert)

Die Frage ist, was besser ist: meine Idee das schon als Konzept in die Basisklasse einzubauen diese Methoden aber leer
zu lassen (ist der Compiler schlau genug das bei Nutzung der Basisklasse als "nop" zu erkennen und somit auszulassen?)
oder alle public Methoden als Virtual zu deklarieren und in der abgeleiteten Klasse zu überschreiben? Wie sieht es mit
dem XMLDOC aus? Muss man den in der abgeleiteten Klasse duplizieren damit er funktioniert?

Grüße
TurboMagic

[Rollo62]

Zitat von himitsu:

TMonitor hat den Vorteil, dass es multiplatform ist (CriticalSection ist ja Windows) und dass es angeblich schneller sein soll.

<OT>
Schneller, einfacher: OK, aber wieso sollte TCriticalSection nicht multiplattform sein ?
https://docwiki.embarcadero.com/Libr...riticalSection

Für asymmetrische Pushs/Pops Szenarios böte sich da auch noch TLightweightMREW an.

</OT>

[Uwe Raabe]

Zitat von Rollo62:

Für asymmetrische Pushs/Pops Szenarios böte sich da auch noch TLightweightMREW an.

Push und Pop sind aber immer schreibende Zugriffe. Insofern sehe ich jetzt noch nicht den Vorteil eines MREW.

[Rollo62]

Zitat von Uwe Raabe:

Dafür würde ich eine eigene Klasse mit separater Implementierung empfehlen. Ich fände es kontraproduktiv, wenn man die wohl unvermeidlichen Performance-Nachteile auch immer für den non-thread Bereich mitschleppen müsste.

Ja an sowas dachte ich eigentlich auch, nur eben auf Basis des TRingBuffer's.
Deshalb frage ich ja ob da schon sowas geplant ist und womöglich kommen wird, oder eher nicht.

Zitat von TurboMagic:

was wäre, wenn man in die Ringpuffer Klasse so wie sie jetzt ist,
je eine Enter und Leave (Exit als Name würde ich wegen dem Keyword
Exit eher nicht bevorzugen) Methode einbaut,

Zitat von himitsu:

[DELPHI]Buffer.Enter;
Buffer.Add(irgendwas);
Buffer.Exit;


type
TRingbuffer<T> = class(Ringbuffer.TRingbuffer<T>)
procedure Enter;
procedure Exit;
end;

Ja sowas ginge auch.
Ich dachte aber eher an eine Klasse die implizit threadsafe ist,
also z.B. TRingbuffer<T> und TRingbuffer_Safe<T>

So dass man die Klasse ohne Änderung beim Aufrufer 1:1 tauschen könnte.

Das separate Enter/Exit hat natürlich auch seine Vorzüge, einer granulareren Steuerung,
wenn man das in vielen unterschiedlichen Szenarien einsetzen würde.
Eigentlich möchte ich nur die laufenden Basic's Push/Pop/Length usw. absichern,
um bedenkenlos Lesen/Schreiben zu können, das wäre doch sehr gut integrierbar.

Welche Vorteile hätte ich denn sonst noch von einem externen, separatem Enter/Exit ?
Da sehe ich eher die Gefahr mal ein Enter/Exit zu vergessen.

Das ist wohl wieder so eine Philosophie-Frage, wo es am Ende zwei Lager gibt
Oder gibt es da einen klaren, technischen Favoriten ?