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.
Stimmt auch wieder, ist ja ein Ring und der muss immer irgendwie geschrieben werden.
Allerdings könnten einige Abfrage-Funktionen womöglich mit InterlockedFunktionen abgesichert werden,
statt mit dem großen TMonitor Aufwand.
Meine aktuelle RingBuffer-Implementierung ist auf der Basis eines TMemoryStreams gemacht
weil es dabei um Byte-Ströme geht, mit CriticalSections, damit bin ich eigentlich ganz zufrieden.
Da nutze ich InterLocked Variablen als Indexzeiger, um unnötige Locks zu Vermeiden.
Ich wollte immer mal checken ob es schnellere, bessere Alternativen gibt.
Der RingBuffer mit ThreadWrapper könnte sowas sein, werde ich mal für mich austesten.
Dein Vorschlag mit dem universellen TThreadWrapper<T: class> = class macht schon viel Sinn,
weil man es dann auch auf viele andere Probleme übertragen kann.
Ich dachte bei dem RingBuffer ursprünglich dass es eine sehr Basic-Library oder Collection ist,
welche ihre eigentliche Aufgabe aus meiner Sicht möglichst komplett eigenständig abdecken sollte.
Das bezog sich aber sehr auf meinen speziellen Anwendungsfall, wo ich Pop/Push möglichst ohne Zusatzaufwand sicher entkoppeln möchte.
Durch den Wrapper wäre die Funktionalität und ThreadSicherheit aber auch schön sauber getrennt, und das passt dann noch in zig andere Situationen rein.
Und ja, Push/Pop/Peek, etc. sorgen dafür dass es doch nicht so einfach intrinsisch threadsicher werden kann,
ich benutze es momentan so, dass wenn was Neues drin ist, dann Lese und Bearbeite es.
Ein Peek nutze ich momentan nicht.
Das Duo mit dem Wrapper gefällt mir immer besser, wenn ich mal tiefer drüber nachdenke.