The main reason for the maximum length is that once the queue is created, you can't create new objects (without potentially blocking in new
or malloc
or whatever is used to create the new object).
I'm not sure there is any solution to that. If allocation locks are acceptable, it wouldn't be that hard to make a lock-free queue that is limited by amount of memory available.
boost::lockfree
does have reserve(n)
and reserve_unsafe(n)
that can be used to grow the queue.
Edit in response to comments:
Yes, the real problems start when two producers are trying to add new elements at the same time, because at some level or another, memory allocation will block until the "leading" thread has completed its allocation. This may of course be acceptable in some cases, but generally, the reason for using lock-free queues is to avoid locks, and having a lock down inside the new
or malloc
isn't still a lock.
If it only happens at relatively rare intervals, it may not be a big deal (depending on the use-case). But if it happens regularly, it will be a problem.
Even with a single producer, there is no guarantee that some other thread isn't calling malloc
or new
somewhere, causing a "wait" in the "add more to the queued".
I think the only real solution is to create a fixed size queue with a big enough size to deal with any possible workload. If the queue itself holds (smart) pointers/references to objects, that may not take up too much memory above and beyond the objects actually being stored in the queue. After all, if you are storing 1000 elements, you need at least 1000 elements worth of storage, whether the queue is dynamic or fixed size.