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.
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,
[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 ?