worse than locked queue

[396848385]

I tried using this lock free queue in our program, but the performance of the task was even worse.

Our program scenario involves multiple queues, each with a fixed number of elements. After an element is retrieved by wait_dequeue, the program performs other operations and then enqueues the element. The purpose of this is to avoid repeatedly creating objects or to block threads in some scenarios to prevent too many threads from executing a logic at the same time

What I want to know is why the performance of this lock free queue is worse than the locked queue that our program already has

[cameron314]

Hard to say why without sample code to investigate.

[396848385]

like this

[396848385]

and this

[cameron314]

That's a start. I see you're using integers. Are you using tokens? What sort of contention is there?

[396848385]

Only a very few scenarios use integer no using tokens. Basically, it's the same usage as the two images above, but after using this lock free queue, my training task time has greatly increased. Do you know what possible reasons are causing this

[cameron314]

For the non-integer types, do they have no-except move constructors? Are they being moved? Consider using producer and consumer tokens. I also encourage you to profile the code to see where the overhead is.