maxSize parameter is not obeyed

[KungFuJesus]

Hello, I'm trying to set a maximum depth with the BlockingReaderWriterQueue so that I can basically spinlock until a thread frees room. However, it seems to allow me to add +1 more than the maximum size (and my max size needs to be 2). A simple example:

#include <readerwriterqueue/readerwriterqueue.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main(void)
{
    moodycamel::BlockingReaderWriterQueue<int> q(2);
    while(!q.try_enqueue(8));
    usleep(50000);
    printf("enqueued 8\n");
    while(!q.try_enqueue(9));
    usleep(50000);
    printf("enqueued 9\n");
    while(!q.try_enqueue(10));
    usleep(50000);
    printf("enqueued 10\n");
    while(!q.try_enqueue(10));
    usleep(50000);
    printf("enqueued 10\n");

    return 0;
}

[cameron314]

maxSize is a minimum. Since the queue needs a spare element internally, it has allocated a block of 4 elements instead, which (minus the reserved one) gives the three slots you see here.

I cannot fix this since number of actual slots must be >= maxSize, and the block size must be a power of 2, so I can't make it exact for all values.

[KungFuJesus]

Doesn't this kind of defeat the purpose of a maxSize parameter? How "approximate" is approx_size? Perhaps I can ping this instead?

[cameron314]

The purpose of maxSize is indeed to limit the number of elements, but while still allowing at least that many elements to be in the queue. (If I wanted to create a queue of 433 elements, I'd be pretty annoyed if I could only enqueue 402 things.) I think name should probably be changed from maxSize to just size. Sorry for the confusion.

approx_size() is always perfectly exact, just not necessarily up to date (if one thread is enqueueing or dequeueing the size perceived by the other thread may be based on stale information). It is eventually consistent.