Ringpuffer Bibliothek veröffentlicht

[TurboMagic]

Hallo,

ich habe soeben eine Bibliothek die ich mal geschrieben hatte als OpenSource auf Github veröffentlicht.
Es ist eine generische Ringpufferumsetzung, also ein Ringpuffer den man problemlos für nicht verwaltete
Datentypen wie Bytes, Integer, Double usw. aber auch für Klassen wie TMyWorkItem usw. nutzen kann.

Das Projekt beinhaltet auch DUnit Tests, wobei sich diese nicht so gut in der IDE ausführen lassen, da
auch geworfene Exceptions getestet werden.

Das Projekt befindet sich hier:
https://github.com/MHumm/CircularBuffer

Es wurde ursprünglich in XE8 begonnen, läuft auch in 10.4 und vermutlich auch in älteren Versionen,
wobei deren Nutzer ruhig mal an ein Update denken dürfen

Wer was zum Projekt beitragen möchte gerne: z.B. fehlen noch ein paar Unit Tests (man sieht welche
noch leer sind) oder die Kommentare (und damit meine ich auch XMLDOC!) sind noch alle auf Deutsch.

Grüße
TurboMagic

[Uwe Raabe]

Warum ist TRingbuffer<T>.Create overload?

[TurboMagic]

Hallo Uwe,

das weiß ich gerade nicht mehr. Gibt's evtl. verschiedene Konstruktoren?
Kannst aber gerne einen Pull Request einreichen. Dann muss ich aber erst
lernen wie man die in Git/Github bearbeitet.

Grüße
TurboMagic

[Uwe Raabe]

Bin gerade dabei die XMLDOC zu übersetzen...

[TurboMagic]

Cool!

[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