Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Возможно твоя критика верна... 22.08.08 22:01 Число просмотров: 2432
Автор: void <Grebnev Valery> Статус: Elderman
|
Возможно твоя критика верна...
> > Ключевой поинт - если завершение операции синхронное
> (в
> > данном случае), то поток может вычитывать данные из
> > системного кэша (которые туда поместил драйвер) без
> > переключения контекста.
> Ээээ.. Чо? :) Есть 2 буфера - драйвера и твой,
> пользовательский (я за сокеты говорю). При любом завершении
> данные из сокетного копируются в твой (если сокетный не
> установлен в 0), из которого ты и будешь брать. А уж
> переключится контекст или нет - оно неведомо в любом
> случае. Не понимаю, где ты тут выиграть хочешь?
Имелось ввиду, что при синхронном завершении чтения данные уже были в буфере драйвера, поэтому последующий вызов read() скопировал данные из буфера драйвера в пользовательский буфер (если размер, размер буфера сокета не 0, иначе драйвер прямо поместил данные в буфер пользователя).
Далее, если операция чтения завершается синхронно несколько раз подряд, то в таком случае можно продолжать "вычитывать" данные из одного и того же потока, не обращаять к очереди IOCP вызывая ::GetQueuedCompletionStatus(...). Т.е. вычитываем, пока вычитывается синхронно. Всё это делается из одного и тогоже потока. Напротив, если мы вызываем ::GetQueuedCompletionStatus(...), то нет гарантии что IOCP будет использовать тот же поток. Конечно, поскольу очередь активных потоков - LIFO, и из за оптимизации IOCP, скорее всего будет использован тот же поток. Но не факт.
>
> > Тогда с большой вероятностью два или
> > более потока (на разных CPU) могут одновременно
> > обрабатывать разные pending issue из очереди IOCP для
> одно
> > и того же сокета вне всякой
> > последовательности:
> Ёптель. Ты несколько раз подряд WSARecv вызываешь что-ли?
> Если да, то ничем помочь не могу, я извращениями не
> занимаюсь ;)
Если "мешать в одном огороде" обработку pending и синхронных операций (то, что ты критикуешь) - это неизбежно, и да, WSARecv (или ReadFile) вызывается несколько раз подряд (фактически столько раз, сколько раз чтение завершается синхронно). Если же операция обрабатыается в логике аппликации как peding(вне зависимости от того, как она фактически завершиласть, синхронно или асинхронно), то WSARecv (или ReadFile) вызывается только один раз.
> Если нет, то, конечно, никаких таких проблем
> нет.
Согласен.
> Кстати, для одновременных запросов WSARecv вполне
> логично их нумеровать, таким образом восстанавливая
> последовательность (но это, повторюсь, извращение).
В принципе хорошая мысль (кажется, народ так и делает). Тогда придётся поддерживать вектор буферов, и каким-то образом "пересобирать" результирующую последовательность байт в соответствии с их "нумерацией". Лично мне кажется это слишком сложным. Проще эксклюзивно заблокировать до тех пор, пока он не завершит чтение. Блокироваться будет только доступ к одному сокету из 1000.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
