Boost logo

Boost Users :

From: Ruediger Berlich (ruediger.berlich_at_[hidden])
Date: 2008-08-07 16:43:44


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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net