If you read more than write, then you can use a sync.RWMutex an RLock when reading, Lock when writing.
Kurtis Rader a következőt írta (2020. november 15., vasárnap, 6:13:03 UTC+1): > On Sat, Nov 14, 2020 at 8:34 PM Robert Engels <ren...@ix.netcom.com> > wrote: > >> That wasn’t my take on the OPs need. He said the consumer is very >> expensive - implying to me they only want to process the latest. If >> dropping the oldest is viable you might as well drop all old entries and >> use the latest. >> > > The O.P. wrote two days ago: > > > Thanks. I want the receiver always get the relately new vaule, I don't > want the sender blocked and I either choose drop the current value or the > first value of the channel. But I don't find a way to safely drop the first > value from the channel. > > In other words, they want the consumer to always fetch, and process, the > oldest available value. They want the producer(s) to always enqueue their > value; even if doing so requires dropping the oldest value from the queue > to make room for the new value. Whether that is sensible behavior, thus > requiring something other than a simple Go channel, is not obvious given > what the O.P. has written so far. > -- > 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/4554312b-e4ea-4f5a-9782-7e2be4154e77n%40googlegroups.com.
