Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AtomicQueueB2 size does not work #28

Closed
pfeatherstone opened this issue Nov 10, 2020 · 8 comments
Closed

AtomicQueueB2 size does not work #28

pfeatherstone opened this issue Nov 10, 2020 · 8 comments

Comments

@pfeatherstone
Copy link

I would expect the following :

atomic_queue::RetryDecorator<atomic_queue::AtomicQueueB2<float>> q(10);
    
    for (size_t i = 0 ; i < 100 ; i++)
    {
        cout << "enqueuing " << i << endl;
        q.push(i);
    }

to only print up to 10 and then hang. But it doesn't. it goes all the way up to 100

@max0x7ba
Copy link
Owner

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.

@pfeatherstone
Copy link
Author

So shouldn't it stop printing at 16 then ?

@max0x7ba
Copy link
Owner

... round up to the next power of two with an extra constraint.

@pfeatherstone
Copy link
Author

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?

@max0x7ba
Copy link
Owner

I would suggest that user to consider AtomicQueue2 and always read the documentation first.

@pfeatherstone
Copy link
Author

What if the size isn't known at compile time ?

@max0x7ba
Copy link
Owner

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.

@pfeatherstone
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants