Every ProducerToken is associated with an inner SPMC queue, while ConsumerToken chooses the best suitable SPMC when the holding thread begins starvation if the originally chosen queue is empty at the time. A shifting rotation will take place. This is the current design for best performance considerations. At runtime, an element enqueues from a given ProducerToken will come out at any ConsumerToken dequeuing operation. Only the relative dequeuing order of the elements enqueuing through the same ProducerToken will be kept after threads competition. But nothing more is guaranteed.
The runtime manner of the dequeuing order adjustments is automatically controlled by the library itself. Here, A feature request can be made, that lets the user decide the association relationship between ProducerToken and ConsumerToken, to achieve the goal that some of the elements enqueuing through a given ProducerToken will be guaranteed to come out from a group of selected(associated) ConsumerTokens. For implementation consideration, the inner rotation of producers can leave the explicitly associated ones alone will be fine.
By sacrificing the performance, this explicit association between ProducerToken and ConsumerToken can provide some sort of element dispatching functionality. Users can still get high performance by creating multiple associated ConsumerToken to that ProducerToken to share the workload in multiple threads.
The reason why the feature is requested is that a scenario was encountered when implementing a dataflow dispatching approach. After digging out from the code, desiredProducer in struct ConsumerToken cannot be controlled by the outside world, while it could solve this problem if the hard link can be made. Currently, multiple queues(BlockingConcurrentQueue was chosen) combination works as an alternative design, that one for the sourcing data and many for each condition.
Thanks for the time to read the request. Sincerely ask for you to consider whether it is suitable for ConcurrentQueue or not. Last but not least, What a great project!
Every ProducerToken is associated with an inner SPMC queue, while ConsumerToken chooses the best suitable SPMC when the holding thread begins starvation if the originally chosen queue is empty at the time. A shifting rotation will take place. This is the current design for best performance considerations. At runtime, an element enqueues from a given ProducerToken will come out at any ConsumerToken dequeuing operation. Only the relative dequeuing order of the elements enqueuing through the same ProducerToken will be kept after threads competition. But nothing more is guaranteed.
The runtime manner of the dequeuing order adjustments is automatically controlled by the library itself. Here, A feature request can be made, that lets the user decide the association relationship between ProducerToken and ConsumerToken, to achieve the goal that some of the elements enqueuing through a given ProducerToken will be guaranteed to come out from a group of selected(associated) ConsumerTokens. For implementation consideration, the inner rotation of producers can leave the explicitly associated ones alone will be fine.
By sacrificing the performance, this explicit association between ProducerToken and ConsumerToken can provide some sort of element dispatching functionality. Users can still get high performance by creating multiple associated ConsumerToken to that ProducerToken to share the workload in multiple threads.
The reason why the feature is requested is that a scenario was encountered when implementing a dataflow dispatching approach. After digging out from the code, desiredProducer in struct ConsumerToken cannot be controlled by the outside world, while it could solve this problem if the hard link can be made. Currently, multiple queues(BlockingConcurrentQueue was chosen) combination works as an alternative design, that one for the sourcing data and many for each condition.
Thanks for the time to read the request. Sincerely ask for you to consider whether it is suitable for ConcurrentQueue or not. Last but not least, What a great project!