информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetПортрет посетителяSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Блокировка российских аккаунтов... 
 Отзыв сертификатов ЦБ РФ, ПСБ,... 
 Памятка мирным людям во время информационной... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Возможно твоя критика верна... 22.08.08 22:01  Число просмотров: 2168
Автор: 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.
<programming> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach