Hi Zeljko,
will be. In the middle of this sits a broker, which takes care of all communication between producers and consumers. Both need to register with the broker before being able to communicate with each other.
Having a single broker for all communication between producers and consumers defeats the point of having threads. Eventually, the broker will become the bottleneck (serialization point). Or did I misunderstand the first sentence?
The part that is indeed serialized this way is the match-making between consumer and producer. Match-making just means fetching the next available producer from a list and connecting it to the consumer. Once that has happened, the match-maker (aka Broker) is free for a new connection. Processing the data takes far longer than the match-making. And what's handed over between producer and consumer in the end is just a shared_ptr (because sometimes a producer might go away and I can't hand back the data. So I don't want a headache with freeing the memory). So most part of the compute time will still be spent concurrently. I have thought of ways of handling even the hand-over concurrently, but I'm not sure they are worth the effort. The data processing time is far too long in comparison to the hand-over. Best, Ruediger