Closed pfeatherstone closed 3 years ago
The size of the queue gets round up to the next power of two with an extra constraint, see https://github.com/max0x7ba/atomic_queue/blob/master/include/atomic_queue/atomic_queue.h#L537
q.capacity()
reports the actual capacity.
So shouldn't it stop printing at 16 then ?
... round up to the next power of two with an extra constraint.
Oh sorry, capacity is 4096. That's quite a way off from desired size 10. Is there a reason to do this? Can't it just be set to what the user wants?
I would suggest that user to consider AtomicQueue2
and always read the documentation first.
What if the size isn't known at compile time ?
The queue is designed for ultra-low-latency and important optimizations require using power-of-2 and also certain minimum capacity. These optimizations can be disabled for queue variants that don't use heap allocation but require capacity to be a compile time constant.
If the capacity isn't known at compile time then I would suggest the user to accept the minimum capacity imposed by AtomicQueueB2
implementation.
Cheers thank you. The other problem for me is the way the queue spins when try_push fails. My apps sometimes have to wait for data. And spinning hogs all the CPU on the calling thread. So maybe a mutex/condvar based queue is best for me. Thanks for the comments though. I should have read the docs more carefully first.
I would expect the following :
to only print up to 10 and then hang. But it doesn't. it goes all the way up to 100