Then R2 kicks in and generates number 4. After that R1 again produces let say 3 numbers (13 24 21). The problem now is how to efficiently (without hashing) figure out that 24 should go into $array3->third track since 20+4=24, and 21 into first track since 17+4=21 and 13 in second or fourth track - it doesn’t matter.

Obviously, everything in the algorithm and its implementation depends on knowing what the rules are... and from your description I can’t guess.

Certainly, I would implement your solution in C++, not C, if it actually comes to that, because in that language you do have ready access to data structures such as queues, balanced-trees and arbitrarily-sized “arrays” (collections ...), all without having to write them from scratch.   (You have better things to do with your time.)   But if your problem really is small, as it superficially appears to be, it seems to me that you don’t have much of a problem here.

Basically, if you can manage to deal with the problem “in memory,” without getting into page-fault hell, you can actually do things in a very brute-force way and get away with it perfectly.   It is, for example, to say #DEFINE MAX_BUCKETS 10000 and thus allocate a fixed-size 10,000-element array and to have your program (check for, and gracefully and meaningfully terminate itself if ...) that limit is ever someday exceeded.   (As I once read in a macabre bit of source code:   “Dig me up and I’ll fix it then ...”   Ick.)   Given that modern processors execute (at least) hundreds of millions of instructions per second, if you can’t clearly demonstrate that a “sophisticated” solution is mandatory in order to solve the problem in all of the cases that you will encounter ... don’t build one.   Unless you can demonstrate that major page-fault activity might happen, the algorithm is going to execute at the full speed of the CPU ... or the maximum speed of the I/O subsystem, whichever is less.

(Whether, by the way, it is implemented in C++ or Perl... for all practical intents and purposes.   The coders who put together perlguts are gods...)

(It goes entirely without saying that if what you are describing is actually some god-awful CPU-intensive operation for some image-processing or cryptographic application or what-have-you, my opinions here would not apply.   But you knew that already, didn’t you?)