简体   繁体   中英

How to implement BlockingCollection to fix this Producer/Consumer issue?

I currently have an app that is receiving packets from a socket, processing them and adding them to a ConcurrentQueue. I then have a separate thread that is processing these items.

The problem I am having is the Producer/Consumer issue where the consumer is trying to take items even when there are not any items, resulting in significant cpu usage.

ProcessPackets is run on its own thread:

    private ConcurrentQueue<PrimaryPacket> Waiting = new ConcurrentQueue<PrimaryPacket>();

    private void ProcessPackets()
    {
        PrimaryPacket e;

        while (true)
        {
            if (Waiting.TryDequeue(out e))
            {
                Packets.TryAdd(((ulong)e.IPAddress << 32 | e.RequestID), e);
            }
        }
    }

    public void AddPacket(PrimaryPacket e)
    {
        Waiting.Enqueue(e);
    }

在此输入图像描述

What would be the best way of implementing the BlockingCollection(T) to deal with this issue? Or another solution?

Also noteworthy, there is about 30,000 items being added to the queue per second.

You don't have to implement BlockingCollection<T> , you can just use it. As the documentation says, it's just a wrapper for IProducerConsumerCollection<T> , such as ConcurrentQueue<T> (which is the default one).

private BlockingCollection<PrimaryPacket> Waiting =
    new BlockingCollection<PrimaryPacket>();

private void ProcessPackets()
{
    while (true)
    {
        PrimaryPacket e = Waiting.Take();
        Packets.TryAdd(((ulong)e.IPAddress << 32 | e.RequestID), e);
    }
}

public void AddPacket(PrimaryPacket e)
{
    Waiting.Add(e);
}

Take() blocks if the queue is empty, so it won't burn CPU unnecessarily. And you should probably consider what to do when the processing is finished.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM