> > The broadcast buffer is a very unique type of structure.
So true! It relies on a nice mechanics similar to StampedLock and is quite ineresting indeed: I have implemented for Agrona a version of it <https://github.com/real-logic/agrona/pull/119> based on the FastFlow-like logic instead to allow "precise" loss counters, but with a finite max length. Probably with actor-like services that provide a finite set of responses with reasonable max lengths, it could be a good match if compared to the original :P Obviously the same usage patterns highlighted by Todd will apply independently by the chosen implementation: the semantic behind a message loss enables lot of interesting logics to be implemented on top, while simiplifying most of the deadlock issues. Il giorno martedì 3 aprile 2018 17:13:31 UTC+2, Todd L. Montgomery ha scritto: > > Good points. The Agrona (and Aeron C versions) do have the proper basic > logic to avoid blocked queues from failure during appends/offers. It's not > simple, but the hard part is done for you. Just need to hook the logic into > a duty cycle. > > The broadcast buffer is a very unique type of structure. It allows for the > case of a slow receiver to fall behind and loose messages rather than block > the transmitter. And it lets the receiver know that this occurred. That > means that some of the interesting deadlocks can be avoided. Recovery of > lost messages (or just resync of state) can be done a number of ways. > Including just a system graceful reset. > > On Tue, Apr 3, 2018 at 7:36 AM, Francesco Nigro <[email protected] > <javascript:>> wrote: > >> There are a couple of things to be considered: >> >> 1. size request and response buffers to avoid deadlocks (there is an >> interesting topic on this list re it too) -> could be used a broadcast >> buffer too to avoid it, but it change the semantic by adding a new >> "failure" state >> 2. consider liveness of processes and blocking operations while >> submitting/reading from the buffers -> Agrona ring buffers has the proper >> API to perform such tests/ops but need to implement the logic >> >> >> Il giorno venerdì 30 marzo 2018 10:55:23 UTC+2, Roman Leventov ha scritto: >>> >>> I think about the possibility of building an asynchronous application >>> with back pressure where some upstream operators are in Java and some >>> downstream ones are in C++. For this purpose, some queues would be needed >>> to pass the data between Java and C++ layers. It seems that porting >>> JCTools's bounded array queues to off-heap should be doable, but I couldn't >>> find existing prototypes or discussions of such thing so maybe I overlook >>> some inherent complications with this idea. >>> >>> Did anybody think about something like this or has implemented in >>> proprietary systems? >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "mechanical-sympathy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
