If you're looking for efficiency, try to sync on a single mutex. The best kind of syncing is the one that didn't happen, depending on your circumstances, pthreads mutex can beat channels even taking into account context switching because syncing on channel isn't free either.
Implementing thread-safe pops() and pushes() to a channel with optional blocking and all that stuff is kind of tricky business and might require extra syncing here and there. If you could decay your problem to sort of single producer single consumer then one mutex per consumer might be enough to sync this and the rest of syncing can be potentially bypassed completely. Of course this depends on specific implementation under the Go channels and may change over time, so this is just guessing and actual performance has to be measured to make any reasonable conclusion. пн, 16 нояб. 2020 г. в 01:44, 陶青云 <qingyu...@gmail.com>: > > > 在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. > > -- > 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/486267f7-c3fc-4563-814a-1fff54bb2d73n%40googlegroups.com. -- 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/CAMteYTbJG1_pdHFdHAYnXhvNM4U0kYVcJVE_8o4fH9xghLcuvA%40mail.gmail.com.
