Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
По поводу new/delete самого ConcreteTopic-а: можно... 28.12.07 15:22 Число просмотров: 5051
Автор: amirul <Serge> Статус: The Elderman
|
> Первая проблема, в том, что для обработки сообщения внутри
> RouterMessageThreadProc надо:
> 1) создать структуру ConcreteTopicA* topicData = new
> ConcreteTopicA
> 2) скопировать данные memmove из transmittedTopic для
> последующей обработки
> 3) удалить структуру delete transmittedTopic;
> Всё это (new, memmove, delete) может быть накладно и долго
> как интерфейса Publisher, так и для самого Router. Кроме
> того, поскольку Publisher может весьма интенсивно обновлять
> данные, это может фрагментировать память и снизить общий
> перформанс.
По поводу new/delete самого ConcreteTopic-а: можно организовать пул (пример пула насколько я помню есть у страуструпа в его C++ Programming Language). Идея в том, чтобы выделить некоторое количество памяти, порезать ее на одинаковые куски и связать куски в односвязный список. Выделение и освобождение памяти в этом пуле - простейшие операции добавления и удаления элемента в голову списка и имеют сложность O(const). Если надо поддержка увеличения, то можно выделять chunk-ами по. В принципе и писать то ничего не надо, все уже есть в boost::pool и в Loki::SmallObjAllocator. Причем решается одновременно и проблема оверхеда по времени и проблема фрагментации памяти.
Что до memmove, то я бы предпочел использовать какую нибудь схему передачи владения (или совместного владения): std::auto_ptr, boost::shared_ptr, boost::intrusive_ptr, Loki::SmartPtr и т.п.. Вместо копирования передать владение (выделить в одном месте, удалить в другом).
> Вторая проблема в том, что при интенсивной посылке
> сообщений в поток, часть сообщений теряется из очереди
> из-за её переполнения (GetLastError
> ==ERROR_NOT_ENOUGH_QUOTA ). Теряется приблизительно 50-80
> сообщений из 1000 000. Изменение, размера очереди потока по
> умолчанию (10000 для W2k/XP/W2k3) - не подходит. Кроме
> того? при переполнении очереди появляется другая, вполне
> ожидаемая и более существенная проблема - сообщения по
> таймеру потока (WM_TIMER) вообще теряют всякий смысл.
А это обязательно использовать стандартные виндовые сообщения?
Как уже написали, самопальная FIFO (std::list или даже std::deque) будет гораздо эффективнее и при этом будет уверенность, что потерявшихся сообщений не будет.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
