информационная безопасность
без паники и всерьез
 подробно о проекте
Где водятся OGRыВсе любят медSpanning Tree Protocol: недокументированное применение
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Критическая уязвимость UEFI позволяет... 
 Японский хостинг попросил клиентов... 
 Компрометация eMudhra вынудила... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[C++] Ну раз гуры не отзываются, попробую высказаться 03.08.08 00:40  Число просмотров: 2443
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Есть два класса recursive_mutex и
> interprocess_recursive_mutex.
> Нафига нужен recursive_mutex, если есть
> interprocess_recursive_mutex с тем же функционалом, да еще
> умеющий работать в разных процессах?

Насколько я понимаю, разница такая же как между виндовыми Mutex-ами и Critical Section-ами. С мьютексами все понятно - это объект ядра, на него есть хендл и при каждом телодвижении в его сторону вызов уходит в ядро, из хендла получается референс на объект и только после этого можно выполнить что либо полезное. После выполнения этой полезной работы выполняется вторая смена контекста (еще чуть к оверхеду). Критическая секция полностью реализована в user-mode dll-ках, подгруженных в память процесса, лежит в user-mode памяти и не требует никаких дополнительных действий для начала выполнения работы.

> То что recursive_mutex не работает там где работает
> interprocess_recursive_mutex - понятно, а наоборот, есть
> usecase'ы ? Т.е. если всегда использовать interprocess -
> граблей собрать можно?

Нет, кроме слегка пониженного перформанса. Но в целом рекомендуется потоки в пределах одного процесса синхронизировать именно критическими секциями (не интерпроцесс).
<programming>
[C++] Господа, а кто гуру в бусте? вопросик есть 01.08.08 20:57  
Автор: PS <PS> Статус: Elderman
<"чистая" ссылка>
Есть два класса recursive_mutex и interprocess_recursive_mutex.
Нафига нужен recursive_mutex, если есть interprocess_recursive_mutex с тем же функционалом, да еще умеющий работать в разных процессах?
То что recursive_mutex не работает там где работает interprocess_recursive_mutex - понятно, а наоборот, есть usecase'ы ? Т.е. если всегда использовать interprocess - граблей собрать можно?

(recursive взят как пример)
[C++] Ну раз гуры не отзываются, попробую высказаться 03.08.08 00:40  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Есть два класса recursive_mutex и
> interprocess_recursive_mutex.
> Нафига нужен recursive_mutex, если есть
> interprocess_recursive_mutex с тем же функционалом, да еще
> умеющий работать в разных процессах?

Насколько я понимаю, разница такая же как между виндовыми Mutex-ами и Critical Section-ами. С мьютексами все понятно - это объект ядра, на него есть хендл и при каждом телодвижении в его сторону вызов уходит в ядро, из хендла получается референс на объект и только после этого можно выполнить что либо полезное. После выполнения этой полезной работы выполняется вторая смена контекста (еще чуть к оверхеду). Критическая секция полностью реализована в user-mode dll-ках, подгруженных в память процесса, лежит в user-mode памяти и не требует никаких дополнительных действий для начала выполнения работы.

> То что recursive_mutex не работает там где работает
> interprocess_recursive_mutex - понятно, а наоборот, есть
> usecase'ы ? Т.е. если всегда использовать interprocess -
> граблей собрать можно?

Нет, кроме слегка пониженного перформанса. Но в целом рекомендуется потоки в пределах одного процесса синхронизировать именно критическими секциями (не интерпроцесс).
1





Рейтинг@Mail.ru


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