С++ и сокеты, архитектура многопоточности

С++11 мультипоточная библиотека в помощь

Boost.Asio

современными средствами

С++

У нас в гугле новые проекты пишут в том числе на плюсах. Но да, когда есть армия задротов, то есть ресурсы повыжимвать такты. Но к плюсам тоже прибегают не всегда. Часто нет смысла

то есть ресурсы повыжимвать такты

Оперативная память уже не ресурс? Или 64 Гб хватит всем?

Иногда не ресурс, особенно для Java кода, которые перебрасывает и обрабатывает сообщения из нескольких С++ систем, которые компактно хранят данные в ОЗУ

А зачем что то улучшать - где ботлнек? Сдается мне что ключевое слово здесь «определенный момент».

Лочится ли очередь пока происходит запись?

Сокет читаешь синхронно? Сокет один, или один на клиента, клиент один?

В общем случае:

Boost.Asio +1

Подумай о boost::asio. Суть выйдет такая: один поток обработки, в нем запущен цикл обработки событий boost::asio::io_service. Все операции с сокетами (boost::asio::ip::tcp::socket) только в этом потоке, т.к. их класс сокета не потокобезопасен. Операции - асинхронный send (async_send) и асинхронный recv (async_receive) - оба не блокируют поток и вызывают в нем же callback по завершении. Обработка, например, в этом же потоке прямо в коллбэке.

там ещё и Java-код есть? Ужос, ужос :)

Как эта планета без Java? Ты что, окстись

Как уже написали, boost::asio, а к нему (почти обязательно) в придачу shared_ptr/weak_ptr, enable_shared_from_this и boost::bind/лямбды. С++ asio - хорошая библиотека.

Как вариант, есть еще libev, но там, скорее всего, не будет многопоточности на уровне клиентского приложения при обработке сокетов - совершенно другая модель, другой мультиплексор по сокетам. Тоже хорошая библиотека, но мне не нравится, что на нее вечно сердит valgrind, или просто готовить libev не умею :) Причем, судя по ману на libev, автор прекрасно осведомлен о такой проблеме.