C++ designalternativ producers/consumers

Har under en tid arbetat med ett projekt men vill bara försäkra mig om att jag har valt rätt väg (alltid svårt när man inte har någon att brainstorma med).
Använder C++11 med Boost och programmet ser ut som följande idag:

Baserat på "tjänster" som kan beskrivas som flera producers, flera consumers.
Tjänsterna är allt från canbus/i2c/websocket/multicast så datatyper jag behöver skicka mellan varje tjänst har ett brett spann..
Använder i idag boost any samt typeid för att lagra godtycklig datatyp i varje transaktion.
En gemensam cirkulär buffert lagrar alla transaktioner och en "Route" klass ser till att dom hamnar rätt (ibland skall samma transaktion till flera mottagare).
Adressering sker med uuid och detta är även basen för "route reglerna".

Använder en sammordnare(klass) som skapar alla tjänster och även tar hand om start/stop/error signalering.
Denna klassen äger även bufferten och agerar som consumer för att distribuera ut transaktionerna(med hjälp av router klassen) till sitt mål (tjänst).
Tjänsterna skriver till bufferten själva (mutex).
Varje transaktion skickas till sitt mål via Asio vilket gör att jag utnyttjar min threadpool för att inte låsa systemet.
Jag har gjort det enkelt för mig och använder shared_ptr för att lagra varje transaktion i bufferten (verkligen dåligt designval med tanke på overhead).

Det fungerar bra och klarar av att hantera några hundra transaktioner i sekunden utan problem på målplattformen som är raspberry pi (cpu belastning sällan över 15-20%).
Men bara för att det fungerar betyder det inte att det är det bästa sättet.
Så utan att posta några tusen rader kod, finns det några andra sätt som är bättre? något jag inte tänkt på?

@RiJo: Tack för input! Skönt att man inte seglat ut i helt vansinniga lösningar

Har sprungit på ett par minor gällande flertrådat och synkronisering så jag hoppas att jag lärt mig något av dom missarna.

Ja prestandan är av vikt och det var där jag lagt mest tid för att få skalningen hyffsat linjär.
Det finns egentligen bara ett krav och det är att inkommande data på en av bussarna måste ovillkorligen generera ett svar inom 50ms annars droppas den anslutningen av servern utanför mitt program. Det löser jag med marginal idag (och gör jag det inte har jag system på plats för att återuppta kommunikationen).
Desto fler kärnor jag kan slänga på programmet desto bättre går det (så länge där finns arbete för alla kärnorna) så skalningen funkar bra.

Utmaningen nu är att optimera tiden varje consumer lägger på att manipulera data och generera eventuella nya transaktioner.
Speciellt att generera data i realtid för användaren via websocket är det som äter upp mest cputid.
Det är som vanligt ett problem när man ska ta massa användarinput i form av strängar och försöka göra något snabbt och smidigt...

Svar på edit: Problemet är att varje service (nästan) alltid är både en consumer/producer så hade blivit en jäkla massa buffertar.
Däremot har tjänsterna som tar extern data en egen mottagningsbuffert just för att inte bli låsta om där blir kö.
Som det är idag så läser jag ju transaktionen från bufferten och sen lägger ut den tillsammans med sin tjänst i exekveringskön (boost asio) så även om det tar en stund att behandla datan så är bufferten fri.

auto transaction = this->m_queue->dequeue();
this->m_asio_strand.dispatch(boost::bind(&Service::process_transaction,
                                service.get(),
                                transaction));

Får väl kanske ta en ny funderare på hur jag löser den biten..
Eventuellt skulle man bara använda signalering att varje tjänst har ett meddelande i bufferten (och buffra dessa signaler) och låta den samordnande klassen läsa varje buffert individuellt istället.
Fördelen då är att jag kan prioritera de tjänsterna som absolut inte får vänta.

@Yoshman: Jag valde shared_ptr just för enkelheten men jag vet, precis som du säger, att det inte är rätt väg att gå.
Tanken är att gå över till rena kopior istället då det handlar om max 10Kb per transaktion i absolut värsta fall.

Första projektet med asio så är mycket möjligt att jag missförstått det helt och hållet när det gäller distribution över flera kärnor..

    boost::thread_group threadGroup;
    boost::asio::io_service asio;
    boost::asio::signal_set signals(asio, SIGINT, SIGTERM, SIGQUIT);
    signals.async_wait(boost::bind(&boost::asio::io_service::stop, &asio));

    std::auto_ptr<boost::asio::io_service::work> work(new boost::asio::io_service::work(asio));

     for (int i = 0; i < thread_count; ++i) {
        threadGroup.create_thread([&]() {
            asio.run();
        });
     }

Tack för tipset angående scoped_lock då det är det mutex:et jag oftast använder!

Transaktioner tar allt mellan 2-3ms till >100ms beroende på vad som ska göras (på rpi).
Allt ifrån att sätta/läsa lite bitar till att logga saker till fil.
Alternativet är att differentiera hanteringen av transaktioner då jag alltid vet vilka tjänster som kommer att generera långsamma exekveringar. Frågan är om det ens är värt jobbet?

Är verkligen guld att få input från andra så bara ös på (om ni orkar)!

@Yoshman: Perfekt!

Går hand i hand med vad jag tänkte mig.
Fördelen är att alla latenskrav jag har på mig sker i tjänster som har väldigt lite jobb att göra (rena kommunikationsenheter).
Handlar iprincip bara om att populera egna datatyper med lite maskning/skiftning och sen skicka vidare (eller ta emot och skicka ut).

Det som sen tar "lång" tid har förvisso också ett latenskrav men inte alls lika strikt utan där räcker
det med att det "upplevs som realtid" vilket ger mig ganska goda marginaler.

Bara att sätta mig vid ritbordet nu då och se vad jag kan få ihop! Tackar hjärtligt för hjälpen!