cameron314 / concurrentqueue

A fast multi-producer, multi-consumer lock-free concurrent queue for C++11
Other
9.53k stars 1.66k forks source link

try_dequeue blocks for up to 10ms (mingw) #299

Closed SnapperTT closed 2 years ago

SnapperTT commented 2 years ago

Firstly, thanks for the great library!

I'm having an issue with gcc-cross compiled x86_64 mingw code:

class Foo {
public:
    moodycamel::BlockingConcurrentQueue<PacketDisassemblyThread_Job_t> leInQueue;
    moodycamel::ConcurrentQueue<PacketDisassemblyThread_Job_t> leOutQueue;
    ...

    void poll(NetworkInterfaceI* NI) {
        Profiler_t P;
        P.push("PacketDisassemblyThread.start"); 
        isPolling = true;
        while (true) {
            PacketDisassemblyThread_Job_t pe;
            leOutQueue.try_dequeue(pe);
                P.push("PacketDisassemblyThread.try_dequeue");
                ...
                // do stuff with pe
                }
           }
}

try_dequeue usually is instant, but sometimes takes up to 10ms to clear. PacketAssemblyThread_Job_t is a small class. Linux gcc performance is fine. Cross compiled mingw code is run on a native windows machine. I have 1 producer and 1 consumer thread.

Compiler:

$ x86_64-w64-mingw32-g++ --version
x86_64-w64-mingw32-g++ (GCC) 11.2.0

Any suggestions? Cheers

cameron314 commented 2 years ago

You're not checking the return value of try_dequeue.

cameron314 commented 2 years ago

How do you know it's taking 10 ms?

SnapperTT commented 2 years ago

It turns out that the constructor for PacketDisassemblyThread_Job_t was taking 10ms. Inside it there was an allocation whose size was uninitialized.

Cheers for your prompt response and sorry to be a trouble mate, my brain has been melted by fixing mingw issues for the last week and my gut instinct was that there might be some kind of mingw/pthreads issue going on under the hood

cameron314 commented 2 years ago

Ah that explains it! :-)