Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / WinForms, .Net Framework Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
 AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9658
Вроде по всем докам Monitor должен работать быстрее, но у меня получается наоборот. Или я что то пропустил?
2 июл 18, 23:18    [21538069]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Сон Веры Павловны
Member

Откуда:
Сообщений: 5299
ViPRos
Вроде по всем докам Monitor должен работать быстрее, но у меня получается наоборот.

Анекдот про сферического коня в вакууме процитировать?
Монитор - это аналог critical section, и существует внутри одного процесса. AutoResetEvent и ManualResetEvent видны в разных процессах, что влечет за собой некоторый оверхед в реализации. Ну, и плюс специфика использования тех и других несколько разная. Вне контекста задачи говорить о предпочтительности использования того или другого бессмысленно.
3 июл 18, 06:13    [21538260]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9658
Сон Веры Павловны,

Безотносительно коней ты тоже сказал что есть оверхед для WaitHandle, чего я не наблюдаю почему то.

А задача такая:
Имеются - {m} работ, {n} ресурсов.
Каждая работа может потребовать некоторое подмножество ресурсов из {n}.
Каждая работа добавляет в {m} новые работы и меняет состояние ресурсов из {n}.
Работа может окончиться неуспешно и вернуться в {m}.

Надо организовать конкурентный доступ к {n} для {m}.
3 июл 18, 09:27    [21538435]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Dima T
Member

Откуда:
Сообщений: 14154
На самом деле зависит от задачи. Event медленнее, но критические секции (Monitor) - это спинлок плюс Event. Т.е. делается N попыток блокировки в цикле, затем при неудаче засыпание на Event.

Если блокировки обычно нет, то Monitor быстрее, если наоборот и все ядра проца загружены, т.е. обычно заблокировано, то медленнее, т.к. впустую тратится процессорное время на спинлок.
3 июл 18, 09:38    [21538454]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9658
Dima T,

где то прочитал, что есть ограничение на количество AutoResetEvents (64), не сталкивался ( я не вижу реакции)?
3 июл 18, 10:34    [21538570]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Dima T
Member

Откуда:
Сообщений: 14154
ViPRos
Dima T,

где то прочитал, что есть ограничение на количество AutoResetEvents (64), не сталкивался ( я не вижу реакции)?

AutoResetEvents это обертка над виндовым Event, для него нет ограничений по количеству.

Есть ограничение 64 для вызова WaitAll() или WaitAny() потому что внутри виндовая WaitForMultipleObjects() и это ее ограничение.

Для Monitor ничего подобного WaitAll()/WaitAny() вообще нет.
3 июл 18, 10:48    [21538589]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9658
Dima T,

хреново что 64, у меня объектов может быть больше намного
3 июл 18, 11:00    [21538616]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
hVostt
Member

Откуда:
Сообщений: 16252
ViPRos
Вроде по всем докам Monitor должен работать быстрее, но у меня получается наоборот. Или я что то пропустил?


Это по каким докам?
3 июл 18, 11:01    [21538619]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
hVostt
Member

Откуда:
Сообщений: 16252
ViPRos,

Если у тебя преимущественно больше чтения, чем записи, можешь посмотреть в сторону ReaderWriterLockSlim.
3 июл 18, 11:08    [21538633]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9658
hVostt
ViPRos
Вроде по всем докам Monitor должен работать быстрее, но у меня получается наоборот. Или я что то пропустил?


Это по каким докам?

MSDN пишет что Monitor эффективнее

Мониторы и дескрипторы ожидания

Важно отметить различия между использованием объектов Monitor класса и WaitHandle объектов.
Monitor Класс полностью управляемые и полностью переносимые, а также могут оказаться эффективными в плане использования ресурсов операционной системы.
Объекты WaitHandle представляют объекты ожидания операционной системы, удобны для синхронизации между управляемым и неуправляемым кодом и предоставляют некоторые расширенные функции операционной системы, например возможность ожидания сразу нескольких объектов.
3 июл 18, 11:23    [21538675]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9658
hVostt
ViPRos,

Если у тебя преимущественно больше чтения, чем записи, можешь посмотреть в сторону ReaderWriterLockSlim.

Задачу я выше описал.
3 июл 18, 11:24    [21538680]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Dima T
Member

Откуда:
Сообщений: 14154
ViPRos
Dima T,

хреново что 64, у меня объектов может быть больше намного

Читай внимательней что я писал.
Еще раз: объектов сколько угодно, хоть 100500, но только 64 объекта можно ждать одновременно (WaitAll() или WaitAny()).
3 июл 18, 11:26    [21538693]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
hVostt
Member

Откуда:
Сообщений: 16252
ViPRos,

Я просто не увидел, с чем сравнивается.


ViPRos
Задачу я выше описал.


Всё равно не понятно, насколько больше чтения, чем записи.
В решении одной задачи у меня смена Monitor на RWSL существенно увеличило производительность, я также учёл переход в режим Update, без рекурсии.
3 июл 18, 11:56    [21538832]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9658
Dima T
ViPRos
Dima T,

хреново что 64, у меня объектов может быть больше намного

Читай внимательней что я писал.
Еще раз: объектов сколько угодно, хоть 100500, но только 64 объекта можно ждать одновременно (WaitAll() или WaitAny()).

ну, я понял, надо делать как и с монитором - не пользоваться WaitAll/Any

Просто я думал - может WaitAll/Any как т по особому этот массив обрабатывают (для массива мониторов нужен еще один монитор - вощем получается многоуровневая структура мониторов)
3 июл 18, 12:18    [21538926]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9658
hVostt
ViPRos,

Я просто не увидел, с чем сравнивается.


ViPRos
Задачу я выше описал.


Всё равно не понятно, насколько больше чтения, чем записи.
В решении одной задачи у меня смена Monitor на RWSL существенно увеличило производительность, я также учёл переход в режим Update, без рекурсии.

Нет ни чтения, ни записи - есть блокировка объектов на время работы критической секции
3 июл 18, 12:20    [21538933]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9658
Интересно, почему нет исходников Enter и т.д. в Monitor.cs
3 июл 18, 12:22    [21538940]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Dima T
Member

Откуда:
Сообщений: 14154
ViPRos
Просто я думал - может WaitAll/Any как т по особому этот массив обрабатывают (для массива мониторов нужен еще один монитор - вощем получается многоуровневая структура мониторов)

По-особому. Потому что внутри используется виндовая WaitForMultipleObjects(), а для мониторов (CRITICAL_SECTION) ничего похожего нет.

PS Если для мониторов ты делал самодельный WaitAll(), то скорее всего он будет тормознее чем WaitAll() для эвентов.

PPS Для твоей задачи можно поизобретать самодельный объект для синхронизации. Менеджер ресурсов. Примерно так: обработчик регистрирует запрос нужных ресурсов и встает на ожидание, менеджер контролирует освобождение ресурсов и как только все нужные освободились - будит обработчика.
3 июл 18, 12:47    [21539007]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Сон Веры Павловны
Member

Откуда:
Сообщений: 5299
ViPRos
Интересно, почему нет исходников Enter и т.д. в Monitor.cs

Потому что они extern c атрибутом MethodImpl, у которого Value = MethodImplOptions.InternalCall, что означает
The call is internal, that is, it calls a method that is implemented within the common language runtime.

(https://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.methodimploptions.aspx)
3 июл 18, 12:54    [21539033]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9658
Dima T
ViPRos
Просто я думал - может WaitAll/Any как т по особому этот массив обрабатывают (для массива мониторов нужен еще один монитор - вощем получается многоуровневая структура мониторов)

По-особому. Потому что внутри используется виндовая WaitForMultipleObjects(), а для мониторов (CRITICAL_SECTION) ничего похожего нет.

PS Если для мониторов ты делал самодельный WaitAll(), то скорее всего он будет тормознее чем WaitAll() для эвентов.

PPS Для твоей задачи можно поизобретать самодельный объект для синхронизации. Менеджер ресурсов. Примерно так: обработчик регистрирует запрос нужных ресурсов и встает на ожидание, менеджер контролирует освобождение ресурсов и как только все нужные освободились - будит обработчика.



Думал о менеджере ресурсов. Но, менеджер этот тоже должен быть синхронизирован.
3 июл 18, 12:55    [21539038]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9658
Наверное, легче сделать иерархию AutoResetEvents (по 64 в блоке), вощем все это я уже делал для монитора
потому что WaitAll действительно по особому
3 июл 18, 12:58    [21539048]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Dima T
Member

Откуда:
Сообщений: 14154
ViPRos
Думал о менеджере ресурсов. Но, менеджер этот тоже должен быть синхронизирован.

Его надо вынести в отдельный поток. Запросы передавать через очередь.
Т.е. сам менеджер однопоточный, ждет сообщения из очереди, по мере поступления обрабатывает.
Внутри сообщения AutoResetEvent для пробуждения обработчика и указание требуемых ему ресурсов.
Т.е. как только ресурсы освободились - будим обработчик и закрепляем ресурсы за ним, по окончании он сообщает что закончил, ресурсы освобождаются и т.д.

Осталось придумать как быстро отслеживать кому какие ресурсы нужны :)
3 июл 18, 13:08    [21539075]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Dima T
Member

Откуда:
Сообщений: 14154
Dima T
Осталось придумать как быстро отслеживать кому какие ресурсы нужны :)

Как вариант: массив счетчиков для обработчиков, при регистрации прописываем их количество:
worker[i] = N

для ресурсов массив массивов (List<List<int>>), т.е. по одному массиву на каждый ресурс, а во внутренний массив писать список обработчиков, ожидающих ресурс.
При регистрации обработчика он добавляется во все ресурсы.

При освобождении ресурса проходим по списку привязанных к нему обработчиков и делаем всем worker[i]--, как только получили 0 - значит все необходимые ресурсы свободны и можно запускать обработчик.
При блокировке ресурса - всем ожидающим worker[i]++

ИМХО в однопоточном варианте должно достаточно быстро работать
3 июл 18, 13:18    [21539101]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Dima T
Member

Откуда:
Сообщений: 14154
Dima T
Как вариант: массив счетчиков для обработчиков, при регистрации прописываем их количество:
worker[i] = N

опечатка: записываем количество требуемых ресурсов.
3 июл 18, 13:20    [21539115]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Dima T
Member

Откуда:
Сообщений: 14154
ViPRos
Наверное, легче сделать иерархию AutoResetEvents (по 64 в блоке), вощем все это я уже делал для монитора
потому что WaitAll действительно по особому

Тут тоже не все просто. Каждый WaitAll() должен работать в своем потоке, затем надо их как-то синхронизировать, т.е. еще один поток ожидающий все первые.
Сразу просматривается проблема: в первом WaitAll() все ресурсы освободились, а во втором - нет. Что дальше делать? Первый сигналит что "свободно" и требует что-то делать, перестать ожидать первые - а вдруг пока второй набор освобождался в первом уже опять что-то заняли.

Как вариант (без больших переделок): разбиваем ресурсы на кучки по 64, ожидание первой (один WaitAll()), при сработке допроверка остальных, если какая-то несвободна, то ждем ее и т.д. по кругу. Как все освободились - закончили ожидание.
3 июл 18, 13:33    [21539166]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9658
Dima T,

этот менеджер скорее всего станет узким местом
у меня тут много режимов работы
однопоточный
2поточный (тут нет блокировок)
многопоточный (управляемое количество потоков)

все это работает в зависимости от структуры ресурсов, характера конкуренции

ну я думал о менеджере много раз не стал реализовывать в коде так как

это долбаные ресурсы любят объединиться в долговременные и кратковременные пулы, одновременно могут быть членами разных пулов, могут блокироваться частично (% мощности) и т.д.
нужны стационарные менеджеры и диспетчеры, которые вообще то сами являются обычными ресурсами и т.д.
хотел как то перевести на Акку, н не получилось концептуально (в мозгах)


а воще то задача - моделировать производственно/финансовые мощности холдинга и построить план работ
3 июл 18, 13:37    [21539191]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4   вперед  Ctrl      все
Все форумы / WinForms, .Net Framework Ответить