The separate write and read pointers do make the array into a ring buffer with simultaneous read and write. I like to use a modulo-two size array and just mask for the low bits. You can write if write_cnt - read_cnt < size, and you can read if write_cnt > read_cnt. The writer can zero the read count and then the write count if the buffer is empty, but due to cache issues it is sometimes safer to just use long long and never zero the counters. Works for bytes, pointers, and arrays of whatever. You can even have the writer double the buffer size on full, copying the bottom half to the top half, and then adjust the mask up a bit. I have a version that recorded the last three relative maxima in usage and adjusted the size down by halves if space was underutilized. It was a structure with a long long write counter, read counter, size-1 mask, a pointer to current space (realloc()able), and stats.

Now if you have a manager thread for writing and another for reading, you can use multiple input buffers, one per writer, and have the manager consolidate them in the central container. A read manager thread can fill output buffers to multiple consumers. If service times are highly variable, output buffers should be shallow (2) so one thread does not end up lagging due to bad luck when all others are done. Excess output threads is more effective than deep buffers dedicated to one thread.

However, one global lock can work, as long as dry reads lead to sufficient sleep to allow writers access. If the readers check the depth before locking to read, even that is not a problem. Writers should check available space before locking to write. It is OK if readers underestimate how much is to be read, and it is OK for writers to underestimate how much space there is to write, for a moment until variables are updated and cache catches up. If they check before the lock, they need not sleep, but a little sleep is nice so the CPUs are shared around.