Allocating producer objects in advance not knowing that threads will become producers?

[totohero]

I would like to allocate memory up-front during initialization step of my application when worker threads have not been created yet.

Creating enough number of ProducerTokens and let each thread pick from it could be one solution but it needs object pool implementation and keeping per-thread, per-queue ProducerToken available to any code is cumbersome.

What could be the best approach to do it?

[cameron314]

Not sure I understand why the worker threads can't allocate their tokens when starting up. Also, would you really need an object pool or would an array with an atomically-incremented index suffice?

Now having said that, explicit producers are reused internally, so creating, say, 8 explicit producer tokens at process startup, then destroying them all, will essentially pre-allocate 8 producers. The worker threads could then create their own producer tokens which would take over the pre-allocated producers automatically, with no additional allocation. In other words, there's essentially already a thread-safe object pool of sorts built into the queue.

Since all producers need to be scanned for elements when attempting to dequeue from an empty queue (worst case), be careful not to create more producers than absolutely necessary.

[totohero]

Thank you for your reply.

To explain more, I am developing an application submodule which is not reponsible for creating worker threads but it can only post task objects to be executed by the worker thread pool. The total number of worker threads in the pool is determined at initialization step but the actual number of threads supposed to process my tasks are varying. The application is periodoc real-time application and submodules are allowed to allocate memory only at initialization step.

If I am understanding your suggestion correctly, I have to pre-allocate producers as many as the total size of the worker thread pool and dequeue will search the all producers in worst case.

I think it would be better if the inactive producer is moved to separate list once the producer is found empty.

[cameron314]

The internal list of producers is add-only in order to remain thread-safe. The worst case applies regardless of whether the producer is active or not; a producer could be attached to a live producer token yet be empty (and conversely a producer token may have been destroyed but its producer could still have elements).