информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Страшный баг в WindowsЗа кого нас держат?Атака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор 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
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Да, супер! 18.06.08 08:43  Число просмотров: 2656
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 18.06.08 09:36  Количество правок: 3
<"чистая" ссылка>
> Результаты тестирования BerkeleyDB DB_QUEUE оказываются
> лучше на ~7% (по скорости) по сравнению с обычной FIFO с
> использованием std::queue на однопроцессорной машине. И это
> при том!, что данные на диске! Видимо там "вылизано"
> всё...
Да, и не нужно забывать, что вылизано не только для разных потоков, но и в принципе, не важно, если продюсер и консумер будут в разных процессах. А «данные на диске» — я уже говорил, что оно там всё меммапится, и винда асинхронно скидывает страницы, доколе BDB конкретно не скажет ей сделать flash. Ну и поскольку мем-маппед, то и все процессы видят всё синхронно.

> Для многопроцессорной машины не тестировал. Надеюсь, что в
> BerkeleyDB нет яных багов относительно синхронизации
> потоков для нескольких CPU. Так что должно работать
> отлично.
Использует объекты синхронизации там, где это надо. Причём, те, которые доступны и максимально эффективны для данной платформы. Короче, долго и печально её оттачивали в основном на nix'ах, там (раньше было, по крайней мере) с объектами синхронизации множество подводных камней и гимора для разных платформ, и они в конце концов пришли к пуленепробиваемости ;-)

> Также есть небольшие баги (например, deadlock-и в случае,
> если get выполнить из того же потока producer), но это
> мелочи.
У BDB есть прекрасный механизм блокировок и их резольвинга, читай доки. Т.е. минимально BDB сама может резольвить их, а максимально — твой отдельный поток может получать информацию о взаимных блокировках и их резольвить как тебе надо.
И ещё — BDB не реентерабельна, это тоже нужно аккуратно учитывать ;-) Т.е. нельзя вызывать функции BDB из колбяк, поведение становится непредсказуемым, или вызывай, пожалуйста, только через другие free-freaded handles.
Ну и, кроме скорости, ещё есть журналирование и транзакции, for sophisticated robust applications, как ты любишь выражаться по-ангельскому ;-)
<programming> Поиск 






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


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