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-sa
If any can be dropped than clearly all are not needed. What is needed differs
greatly if you have a billion events versus 10. Without more information on the
system you cannot create an appropriate design.
It is my guess that a simple hand off queue will suffice in this case.
(Otherwise you nee
On Sun, Nov 15, 2020 at 7:21 PM Robert Engels wrote:
> I will argue if it is ok to drop the oldest then it is ok to drop all but
> the latest. You need more metrics on volume and latency requirements to
> know which is the proper approach.
>
If true your solution implies the O.P.'s question is a
I will argue if it is ok to drop the oldest then it is ok to drop all but the
latest. You need more metrics on volume and latency requirements to know which
is the proper approach.
> On Nov 15, 2020, at 8:01 PM, Kurtis Rader wrote:
>
>
>> On Sun, Nov 15, 2020 at 3:45 PM 陶青云 wrote:
>
>>
>
On Sun, Nov 15, 2020 at 3:45 PM 陶青云 wrote:
>
> 在2020年11月15日星期日 UTC+8 下午12:19:07 写道：
>
>> On Sat, Nov 14, 2020 at 7:54 PM Robert Engels
>> 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 p
在2020年11月15日星期日 UTC+8 下午12:19:07 写道：
> On Sat, Nov 14, 2020 at 7:54 PM Robert Engels
> 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 co
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
> wrote:
>
>> That wasn’t my take on the OPs need. He said the c
On Sat, Nov 14, 2020 at 8:34 PM Robert Engels 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. w
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.
Pretty common in trading systems with a price feed - in many cases only
On Sat, Nov 14, 2020 at 7:54 PM Robert Engels 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 it
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
On Sat, Nov 14, 2020 at 5:43 PM 陶青云 wrote:
> Don't use channels for this. It's not what they are for.
>>
>> Ian
>
> I see some examples using the buffered channel as a job queue. Could you
> give me some advise on this.
>
If you search for terms like "go channel job queue" you'll find examples
t
在2020年11月14日星期六 UTC+8 上午3:09:24 写道：
> If I understand what you're trying to do, I'd approach it this way, using
> a generously buffered channel and discarding the extras at the consumer, as
> shown below, instead of at the producer:
>
> result <- c // wait for result to appear
> for len(c) > 0
在2020年11月13日星期五 UTC+8 下午11:19:46 写道：
> On Thu, Nov 12, 2020 at 11:13 PM 陶青云 wrote:
> >
> >
> > It is not a one-length buffered channel. I need to drop because the
> recveiver do heavy work that can't process as quickly as sender.
>
> Don't use channels for this. It's not what they are for.
If I understand what you're trying to do, I'd approach it this way, using a
generously buffered channel and discarding the extras at the consumer, as
shown below, instead of at the producer:
result <- c // wait for result to appear
for len(c) > 0 {
// there is a newer result available
re
I see some smart people suggesting that what OP is doing is not
correct. I am going to cautiously disagree with some of those replies
and suggest that a similar pattern can be useful for some
applications.
We have an application where we have a similar need. Specifically,
there is a periodic tic
Try to use two channels: one to signal that the receiver needs a new
value and another one to send new value to the receiver. Supposedly
the sender won't block if you're using `select` to check what
receivers need values, and the receiver can block until a new value is
arrived at the input channel.
On Fri, Nov 13, 2020 at 8:12 AM 陶青云 wrote:
>
> It is not a one-length buffered channel. I need to drop because the
> recveiver do heavy work that can't process as quickly as sender.
>
You need to write a flow control scheme then. Channels may be part of the
solution, but they can't solve it on
On Thu, Nov 12, 2020 at 11:13 PM 陶青云 wrote:
>
>
> It is not a one-length buffered channel. I need to drop because the
> recveiver do heavy work that can't process as quickly as sender.
Don't use channels for this. It's not what they are for.
Ian
> 在2020年11月13日星期五 UTC+8 下午2:36:13 写道：
>>
>>
It is not a one-length buffered channel. I need to drop because the
recveiver do heavy work that can't process as quickly as sender.
在2020年11月13日星期五 UTC+8 下午2:36:13 写道：
> On Thu, Nov 12, 2020 at 9:32 PM 陶青云 wrote:
>
>> Thanks. I want the receiver always get the relately new vaule, I don't
>>
On Thu, Nov 12, 2020 at 9:32 PM 陶青云 wrote:
> 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.
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.
Maybe like this ?
```
// c is buffered channel
s
On Thu, Nov 12, 2020 at 6:19 PM 陶青云 wrote:
> ```
> // c is buffered channel
> select {
> case c <- result:
> default:
> // full, drop old one
> <-c
> c <- result
> }
> ```
>
> I have a code like this, but there may be a race condition in the default
> case. I enconter a
> dead
On Thu, Nov 12, 2020 at 6:19 PM 陶青云 wrote:
>
> ```
> // c is buffered channel
> select {
> case c <- result:
> default:
> // full, drop old one
> <-c
> c <- result
> }
> ```
>
> I have a code like this, but there may be a race condition in the default
> case. I enconter a
> de
```
// c is buffered channel
select {
case c <- result:
default:
// full, drop old one
<-c
c <- result
}
```
I have a code like this, but there may be a race condition in the default
case. I enconter a
deadlock that the goroutine block on 'c<'.
--
You received this message
25 matches
Mail list logo
