On Sun, Nov 15, 2020 at 3:45 PM 陶青云 <qingyu...@gmail.com> wrote:
> > 在2020年11月15日星期日 UTC+8 下午12:19:07<Kurtis Rader> 写道： > >> On Sat, Nov 14, 2020 at 7:54 PM Robert Engels <ren...@ix.netcom.com> >> wrote: >> >>> I don’t think a ring buffer works. At least in a traditional ring buffer >>> the producer cannot pass the consumer - if the buffer is full the producer >>> blocks or drops. Trying to ensure the consumer always reads the most recent >>> available item is better (and more simply) served with a shared hand off >>> queue. >>> >> >> It is trivial to create a ring buffer type that drops the oldest queued >> item when appending a new item if the ring is full. Which would seem to be >> the behavior the O.P. wants. The important question in this scenario is >> whether such an object must be useful in a `select` statement. If not the >> implementation is borderline trivial. >> >> The ring buffer should work, but it seems to need the consumer to test > and sleep when the ring is empty, which is not as efficient as a channel. > If I was doing this in C I would use a counting semaphore. In Go create a channel of the empty interface. Whenever the producer adds an entry to the ring, and the ring isn't already full, it sends `nil` on the channel. When the consumers/workers receive a `nil` token from the channel they know there is a new entry in the ring buffer to be processed. Voila! Your ring buffer now plays nicely with `select. Note that you still need a spinlock to protect modifications of the ring buffer by the producer(s) and consumers. -- Kurtis Rader Caretaker of the exceptional canines Junior and Hank -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CABx2%3DD9ct-BBJskMmXn-88E6HtJEciEyFpOOYpi9yAFWAtpLCA%40mail.gmail.com.
