информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Страшный баг в WindowsВсе любят медСетевые кракеры и правда о деле Левина
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Фишинговая атака на Python-разработчиков 
 ФБР нашла русский след в атаках... 
 Массовый взлом SharePoint 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
slim write/read lock 06.07.08 06:04  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
Пока не могу понять преимущество (а вообще говоря и возможность) использования SRWLOCK (Vista/Windows2008) в большинстве задач FIFO/LIFO (queue/list/stack/cyclic buffer и т.д.). Сложность в понимании в том, что в большинстве указанных задач, reader так или иначе изменяет состояние контейнера (pop.front для/change tail и т.д.). Это не возможно сделать только на AcquireSRWLockShared, но на AcquireSRWLockExclusive. Пример CQueue, из новой книжки Рихтера "Windows via C/C++, Fifth Edition" также вызывает сомнение, поскольку reader изменяет элемент CQueue.

Согласен, что SRWLOCK возможно даст перформанс в задачах где несколько читателейтолькочитают данные из контейнера, но это слабое утешение, поскольку крайне сужает круг практических задач.

Какие будут мнения? Как-так построить, скажем, queue, чтобы reader не менял состояние очереди?
1




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


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