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

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

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

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

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

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

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

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

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

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

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

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

Откуда:
Сообщений: 14503
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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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


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

Откуда:
Сообщений: 9739
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

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

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


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


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

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

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

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

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

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

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

Откуда:
Сообщений: 5507
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

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

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

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

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



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

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

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

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

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

Откуда:
Сообщений: 14503
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

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

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

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

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

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

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

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

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

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

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


а воще то задача - моделировать производственно/финансовые мощности холдинга и построить план работ
3 июл 18, 13:37    [21539191]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Dima T
Member

Откуда:
Сообщений: 14503
ViPRos
этот менеджер скорее всего станет узким местом

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

ViPRos
хотел как то перевести на Акку, н не получилось концептуально (в мозгах)

ИМХО задача не подходит для Акки.
3 июл 18, 13:48    [21539236]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

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

ну, менеджер этот в мозгах уже лет 20 сидит, но он сцуко один в один повторяет структуру предприятия
а в структуре есть и мобильные ресурсы (активные и пассивные) - транспорт, многостаночники, наладчики

даже стационарные непросты - хорошо когда рабочее место содержит стационарный станок, набор инструментов, приспособлений, прикрепленного набора рабочих, а есть просто пустое место, где можно собраться и поработать вместе мобильным и .д.

очень сложная структура и объекты все со сложным поведением


при этом!!! - сама критическая секция (запланировать единицу работы) работает так быстро, что телодвижения с блокировкой этих ресурсов отнимают офигенное количество времени
когда мощности хорошо сбалансированы под работы не особо большая разница во времени, что в один поток, что в 100

потому остерегаюсь создавать эти менеджеры - пытаюсь обойтись примитивами
но когда нить для души попробую полностью симулировать
3 июл 18, 14:16    [21539343]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
А так все это один в один повторяет механизм эскалации блокировок МССКЛ :)
3 июл 18, 14:17    [21539347]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
сейчас вообще то у меня самая серьезная проблема - запись сгенерированной информации в СУБД
на ноуте за минуту генерируется 1000 000 процессов (~ 10 000 000 записей) а запись отнимает 5-7 минут (с учетом всех распараллеливаний, симплов, балков, 610 и т.д фигни)
куда бы архитектурно эту инфу сбагрить бл*
3 июл 18, 14:23    [21539369]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
а в реале надо 50 - 70 000 000 процессов и хорошо бы не больше тех 1-5 минут
3 июл 18, 14:24    [21539376]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Dima T
Member

Откуда:
Сообщений: 14503
ViPRos
при этом!!! - сама критическая секция (запланировать единицу работы) работает так быстро, что телодвижения с блокировкой этих ресурсов отнимают офигенное количество времени
когда мощности хорошо сбалансированы под работы не особо большая разница во времени, что в один поток, что в 100

Код надо смотреть, так сложно что-то понять.

ViPRos
потому остерегаюсь создавать эти менеджеры - пытаюсь обойтись примитивами
но когда нить для души попробую полностью симулировать

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

ИМХО мой вариант с "кучками" 21539166 может заработать и переделка небольшая.
3 июл 18, 14:59    [21539482]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

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

Ну, я ж согласился что надо блоками ивентов управлять
Я почему то думал, что монитор что то легковесное (в принципе везде так и написано, а исходников нет что бы посмотреть)
3 июл 18, 15:23    [21539556]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
Код (создание процесса - очень большой), а так

начало
                    var alg = algroup.Where(ag => stru.Equals(Guid.Empty) || ag.Value.Select(v => v.struel).Contains(stru)).ToArray();

                    if (autoResetEvents)
                    {
                        lock (algroup)
                        {
                            lock (areLockStru)
                            {
                                foreach (var g in alg)
                                {
                                    var dstru = g.Value.Select(v => v.struel).FirstOrDefault();
                                    AutoResetEvent ev;
                                    if (!areLockStru.TryGetValue(dstru, out ev))
                                    {
                                        ev = new AutoResetEvent(true);
                                        areLockStru.Add(dstru, ev);
                                    }
                                    if (!areEventsObjects.Contains(ev)) areEventsObjects.Add(ev);
                                }
                            }
                        }
                        AutoResetEvent.WaitAll(areEventsObjects.ToArray());
                    }
                    else
                    {
                        if (monitorEvents)
                        {
                            lock (algroup)
                            {
                                lock (monLockStru)
                                {
                                    foreach (var g in alg)
                                    {
                                        var dstru = g.Value.Select(v => v.struel).FirstOrDefault();
                                        object ev;
                                        if (!monLockStru.TryGetValue(dstru, out ev))
                                        {
                                            ev = new object();
                                            monLockStru.Add(dstru, ev);
                                        }
                                        if (!monitorEventsObjects.Contains(ev)) monitorEventsObjects.Add(ev);
                                    }
                                    foreach (var e in monitorEventsObjects) Monitor.Enter(e);
                                }
                            }
                        }
                    }


-----------блабла


и конец

                if (autoResetEvents)
                {
                    foreach (var ev in areEventsObjects) ev.Set();
                    areEventsObjects.Clear();
                }
                else
                {
                    if (monitorEvents)
                    {
                        foreach (var ev in monitorEventsObjects) Monitor.Exit(ev);
                        monitorEventsObjects.Clear();
                    }
                }
3 июл 18, 15:27    [21539568]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
hVostt
Member

Откуда:
Сообщений: 16793
ViPRos
сейчас вообще то у меня самая серьезная проблема - запись сгенерированной информации в СУБД


у тебя?

вообще-т 99% узких мест, это IO операции.

если нет желания/возможности масштабирования операций, то в сторону акка нет смысла.

думал о реактивном подходе?
3 июл 18, 15:31    [21539577]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
hVostt
Member

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

если бы ты работал с асинхронным IO, то Monitor тут не получится использовать
3 июл 18, 15:34    [21539582]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
hVostt
если нет желания/возможности масштабирования операций, то в сторону акка нет смысла.

думал о реактивном подходе?

ну, акка просто не подходит, неохота вспоминать почему
все эти rx тоже под наблюдением
пока что лучше всего TPL DataFlow, но для того что бы перейти надо кучу вещей переписать - создать конвеер
3 июл 18, 15:42    [21539604]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
hVostt
Member

Откуда:
Сообщений: 16793
ViPRos
lock (algroup)


Почему не использовать потокобезопасные коллекции? Так блокировать коллекции не по феншую, да и не блокирует доступ к коллекции.
3 июл 18, 15:45    [21539620]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
hVostt
Member

Откуда:
Сообщений: 16793
ViPRos
ну, акка просто не подходит, неохота вспоминать почему


Да тут и нечего вспоминать, весь смысл акторов в масштабировании, кто бы там чего не говорил. В рамках одного процесса акторы -- оверхед без видимого профита.

ViPRos
пока что лучше всего TPL DataFlow, но для того что бы перейти надо кучу вещей переписать - создать конвеер


Неблокирующий конвеер -- наверное лучшее, что можно придумать, согласен.
3 июл 18, 15:47    [21539626]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Dima T
Member

Откуда:
Сообщений: 14503
                            lock (algroup)
                            {
                                lock (monLockStru)
                                {
                                    foreach (var g in alg)
                                    {
                                        var dstru = g.Value.Select(v => v.struel).FirstOrDefault();
                                        object ev;
                                        if (!monLockStru.TryGetValue(dstru, out ev))
                                        {
                                            ev = new object();
                                            monLockStru.Add(dstru, ev);
                                        }
                                        if (!monitorEventsObjects.Contains(ev)) monitorEventsObjects.Add(ev);
                                    }
                                    foreach (var e in monitorEventsObjects) Monitor.Enter(e);
                                }
                            }

У тебя захват блокировок внутри блокировки, т.е. чтобы начать захватывать ресурсы надо захватить algroup и monLockStru. Это гарантирует что все задачи последовательно будут выполнятся, т.к. пока хоть одна задача висит на ожидании какого-нибудь ресурса, то другие потоки висят на lock (algroup)

Как минимум надо вынести этот цикл за lock (algroup)
foreach (var e in monitorEventsObjects) Monitor.Enter(e);
3 июл 18, 15:49    [21539630]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

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

если бы ты работал с асинхронным IO, то Monitor тут не получится использовать

IO асинхронная (в таких же тасках, без begin/end)

Монитор в принципе плохой, его самого надо монитором закрывать, а не то стартуют процессы - клоны
а чем асинхронность записи мешает монитору не знаю
3 июл 18, 15:51    [21539639]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
hVostt
Member

Откуда:
Сообщений: 16793
ViPRos
if (monitorEvents)
                        {
                            lock (algroup)
                            {


if надо либо ещё раз выполнять после входа в критическую секцию, или выполнять внутри, иначе это небезопасно :)
3 июл 18, 15:52    [21539643]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
Dima T
                            lock (algroup)
                            {
                                lock (monLockStru)
                                {
                                    foreach (var g in alg)
                                    {
                                        var dstru = g.Value.Select(v => v.struel).FirstOrDefault();
                                        object ev;
                                        if (!monLockStru.TryGetValue(dstru, out ev))
                                        {
                                            ev = new object();
                                            monLockStru.Add(dstru, ev);
                                        }
                                        if (!monitorEventsObjects.Contains(ev)) monitorEventsObjects.Add(ev);
                                    }
                                    foreach (var e in monitorEventsObjects) Monitor.Enter(e);
                                }
                            }

У тебя захват блокировок внутри блокировки, т.е. чтобы начать захватывать ресурсы надо захватить algroup и monLockStru. Это гарантирует что все задачи последовательно будут выполнятся, т.к. пока хоть одна задача висит на ожидании какого-нибудь ресурса, то другие потоки висят на lock (algroup)

Как минимум надо вынести этот цикл за lock (algroup)
foreach (var e in monitorEventsObjects) Monitor.Enter(e);


Этих algroup много - lock (algroup) пропускает неоднотипные процессы

а если не сделать lock (monLockStru) то все однотипные процессы ломанутся одновременно и будет дедлок
3 июл 18, 15:54    [21539647]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Dima T
Member

Откуда:
Сообщений: 14503
foreach (var e in monitorEventsObjects) Monitor.Enter(e);

так делать тоже нельзя, т.к. ты заранее блокируешь ресурсы. Например тебе надо ресурсы 1,3,5. В этом цикле ты заблокировал 1 и 3, а 5 оказался занят и ты повис в ожидании, но при этом 1 и 3 тобой заблокированы, но ты ими не пользуешься, т.к. ждешь 5.
3 июл 18, 15:54    [21539649]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
это такое двойное сито перед блокировкой
3 июл 18, 15:54    [21539650]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
Dima T
foreach (var e in monitorEventsObjects) Monitor.Enter(e);

так делать тоже нельзя, т.к. ты заранее блокируешь ресурсы. Например тебе надо ресурсы 1,3,5. В этом цикле ты заблокировал 1 и 3, а 5 оказался занят и ты повис в ожидании, но при этом 1 и 3 тобой заблокированы, но ты ими не пользуешься, т.к. ждешь 5.


именно для этого и блокировка lock (monLockStru)
3 июл 18, 15:55    [21539654]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
hVostt
Member

Откуда:
Сообщений: 16793
ViPRos
Монитор в принципе плохой, его самого надо монитором закрывать, а не то стартуют процессы - клоны
а чем асинхронность записи мешает монитору не знаю


тем, что код, находящийся после await, может быть выполнен в другом потоке, соответственно, блокировка на поток может быть проигнорирована, что приведёт к дедлоку.

т.е. надо использовать семафоры.
3 июл 18, 15:55    [21539655]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
hVostt
ViPRos
Монитор в принципе плохой, его самого надо монитором закрывать, а не то стартуют процессы - клоны
а чем асинхронность записи мешает монитору не знаю


тем, что код, находящийся после await, может быть выполнен в другом потоке, соответственно, блокировка на поток может быть проигнорирована, что приведёт к дедлоку.

т.е. надо использовать семафоры.

ну можно указать контекст если надо
3 июл 18, 15:55    [21539657]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
hVostt
ViPRos
if (monitorEvents)
                        {
                            lock (algroup)
                            {


if надо либо ещё раз выполнять после входа в критическую секцию, или выполнять внутри, иначе это небезопасно :)

это поле статик - задается при конфигурации
3 июл 18, 15:57    [21539667]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38643
hVostt
ViPRos
lock (algroup)



Почему не использовать потокобезопасные коллекции? Так блокировать коллекции не по феншую, да и не блокирует доступ к коллекции.

+1
Тогда и сабж монитор не понадобится)
3 июл 18, 15:58    [21539669]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
Да все в этом коде рабочее и протестировано
3 июл 18, 15:58    [21539672]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
hVostt
Member

Откуда:
Сообщений: 16793
ViPRos
это поле статик - задается при конфигурации


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

Откуда:
Сообщений: 9739
hVostt
ViPRos
lock (algroup)


Почему не использовать потокобезопасные коллекции? Так блокировать коллекции не по феншую, да и не блокирует доступ к коллекции.

они все потокобезопасные :)
но их можно использовать как объект блокировки
3 июл 18, 16:00    [21539677]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
Petro123
hVostt
пропущено...


Почему не использовать потокобезопасные коллекции? Так блокировать коллекции не по феншую, да и не блокирует доступ к коллекции.

+1
Тогда и сабж монитор не понадобится)

пшел нах
3 июл 18, 16:00    [21539680]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
hVostt
Member

Откуда:
Сообщений: 16793
hVostt
ViPRos
это поле статик - задается при конфигурации


это все выглядит как костыли, может лучше бы подошли потокобезопасные очереди.


хотя может это тот случай, когда что-то рабочее за вменяемое время написать -- уже победа.
3 июл 18, 16:00    [21539681]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
hVostt
Member

Откуда:
Сообщений: 16793
ViPRos
они все потокобезопасные :)
но их можно использовать как объект блокировки


это только если ты знаешь, что к коллекции надо обращаться только через критическую секцию, так делать не рекомендуется, настоятельно :)
3 июл 18, 16:01    [21539686]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
hVostt
Member

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

или ты просто сэкономил на лок-объкете )
3 июл 18, 16:02    [21539691]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
hVostt
hVostt
пропущено...


это все выглядит как костыли, может лучше бы подошли потокобезопасные очереди.


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

Хвост не горячись - потокобезопасность коллекции делают потокобезопасным только их, а не твой код
все коллекции там потокобезопасные (кроме особых случаев - созданы только для лока)
3 июл 18, 16:02    [21539692]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

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

или ты просто сэкономил на лок-объкете )

ну я ж прогер 40 летним стажем :) ячейка память бережет!
3 июл 18, 16:03    [21539696]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Dima T
Member

Откуда:
Сообщений: 14503
ViPRos
Этих algroup много - lock (algroup) пропускает неоднотипные процессы

а если не сделать lock (monLockStru) то все однотипные процессы ломанутся одновременно и будет дедлок

Но в коде с эвентами вызов WaitAll() вынесен за блокировку. Если не путаю WaitAll() не блокирует AutoResetEvent, в WinAPI это так, как тут - не знаю. Если так, то у тебя вообще нет блокировок AutoResetEvent.
3 июл 18, 16:06    [21539707]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
Dima T
ViPRos
Этих algroup много - lock (algroup) пропускает неоднотипные процессы

а если не сделать lock (monLockStru) то все однотипные процессы ломанутся одновременно и будет дедлок

Но в коде с эвентами вызов WaitAll() вынесен за блокировку. Если не путаю WaitAll() не блокирует AutoResetEvent, в WinAPI это так, как тут - не знаю. Если так, то у тебя вообще нет блокировок AutoResetEvent.

Ты не внимателен - коллекции areEvents, monEvents локальные
3 июл 18, 16:09    [21539722]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
а блокировка сразу задается в конструкторе ивента
3 июл 18, 16:09    [21539726]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38643
ViPRos,
Как сказал ....."ты злишься, значит неправ))"
3 июл 18, 16:10    [21539728]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
Petro123
ViPRos,
Как сказал ....."ты злишься, значит неправ))"

не я не злюсь, просто мы кои-то веки без тебя тут пару часов по человечески поговорили, а тут ты!
3 июл 18, 16:12    [21539737]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Dima T
Member

Откуда:
Сообщений: 14503
ViPRos
Ты не внимателен - коллекции areEvents, monEvents локальные

Я про lock (algroup). Эвенты ждутся после этого лока, а мониторы внутри.
+ выделил нужные строки
ViPRos
Код (создание процесса - очень большой), а так

начало
                    var alg = algroup.Where(ag => stru.Equals(Guid.Empty) || ag.Value.Select(v => v.struel).Contains(stru)).ToArray();

                    if (autoResetEvents)
                    {
                        lock (algroup)
                        {
                            lock (areLockStru)
                            {
                                foreach (var g in alg)
                                {
                                    var dstru = g.Value.Select(v => v.struel).FirstOrDefault();
                                    AutoResetEvent ev;
                                    if (!areLockStru.TryGetValue(dstru, out ev))
                                    {
                                        ev = new AutoResetEvent(true);
                                        areLockStru.Add(dstru, ev);
                                    }
                                    if (!areEventsObjects.Contains(ev)) areEventsObjects.Add(ev);
                                }
                            }
                        }
                       AutoResetEvent.WaitAll(areEventsObjects.ToArray());
                    }
                    else
                    {
                        if (monitorEvents)
                        {
                            lock (algroup)
                            {
                                lock (monLockStru)
                                {
                                    foreach (var g in alg)
                                    {
                                        var dstru = g.Value.Select(v => v.struel).FirstOrDefault();
                                        object ev;
                                        if (!monLockStru.TryGetValue(dstru, out ev))
                                        {
                                            ev = new object();
                                            monLockStru.Add(dstru, ev);
                                        }
                                        if (!monitorEventsObjects.Contains(ev)) monitorEventsObjects.Add(ev);
                                    }
                                    foreach (var e in monitorEventsObjects) Monitor.Enter(e);
                                }
                            }
                        }
                    }


-----------блабла


и конец

                if (autoResetEvents)
                {
                    foreach (var ev in areEventsObjects) ev.Set();
                    areEventsObjects.Clear();
                }
                else
                {
                    if (monitorEvents)
                    {
                        foreach (var ev in monitorEventsObjects) Monitor.Exit(ev);
                        monitorEventsObjects.Clear();
                    }
                }

Про блокировку AutoResetEvent.WaitAll() ничего не нашел, в хэлпе только про WaitOne()
3 июл 18, 16:17    [21539759]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38643
ViPRos
они все потокобезопасные :)

Сожалею, но это не отмаз).
3 июл 18, 16:20    [21539771]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
Dima T
ViPRos
Ты не внимателен - коллекции areEvents, monEvents локальные

Я про lock (algroup). Эвенты ждутся после этого лока, а мониторы внутри.
+ выделил нужные строки
ViPRos
Код (создание процесса - очень большой), а так

начало
                    var alg = algroup.Where(ag => stru.Equals(Guid.Empty) || ag.Value.Select(v => v.struel).Contains(stru)).ToArray();

                    if (autoResetEvents)
                    {
                        lock (algroup)
                        {
                            lock (areLockStru)
                            {
                                foreach (var g in alg)
                                {
                                    var dstru = g.Value.Select(v => v.struel).FirstOrDefault();
                                    AutoResetEvent ev;
                                    if (!areLockStru.TryGetValue(dstru, out ev))
                                    {
                                        ev = new AutoResetEvent(true);
                                        areLockStru.Add(dstru, ev);
                                    }
                                    if (!areEventsObjects.Contains(ev)) areEventsObjects.Add(ev);
                                }
                            }
                        }
                       AutoResetEvent.WaitAll(areEventsObjects.ToArray());
                    }
                    else
                    {
                        if (monitorEvents)
                        {
                            lock (algroup)
                            {
                                lock (monLockStru)
                                {
                                    foreach (var g in alg)
                                    {
                                        var dstru = g.Value.Select(v => v.struel).FirstOrDefault();
                                        object ev;
                                        if (!monLockStru.TryGetValue(dstru, out ev))
                                        {
                                            ev = new object();
                                            monLockStru.Add(dstru, ev);
                                        }
                                        if (!monitorEventsObjects.Contains(ev)) monitorEventsObjects.Add(ev);
                                    }
                                    foreach (var e in monitorEventsObjects) Monitor.Enter(e);
                                }
                            }
                        }
                    }


-----------блабла


и конец

                if (autoResetEvents)
                {
                    foreach (var ev in areEventsObjects) ev.Set();
                    areEventsObjects.Clear();
                }
                else
                {
                    if (monitorEvents)
                    {
                        foreach (var ev in monitorEventsObjects) Monitor.Exit(ev);
                        monitorEventsObjects.Clear();
                    }
                }

Про блокировку AutoResetEvent.WaitAll() ничего не нашел, в хэлпе только про WaitOne()


Ну все правильно
==> foreach (var e in monitorEventsObjects) Monitor.Enter(e);
установили блокировку (только не для себя, мы не ждем эти события - мы их для других поставили)

тут тоже для себя зеленая дорога (сигнал установлен в конструкторе), а после WaitAll двери захлопываются
3 июл 18, 16:26    [21539793]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38643
System.collections.concurrent.
Минимальный лок на минимальное время содердится в коде метода
List.Add(Object).
А потом уже мониторы, семафоры и блок по логике процессов.
3 июл 18, 16:27    [21539796]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
hVostt
Member

Откуда:
Сообщений: 16793
ViPRos
Ну все правильно
==> foreach (var e in monitorEventsObjects) Monitor.Enter(e);
установили блокировку (только не для себя, мы не ждем эти события - мы их для других поставили)

тут тоже для себя зеленая дорога (сигнал установлен в конструкторе), а после WaitAll двери захлопываются


всё же тут напрашивается rx )
3 июл 18, 16:29    [21539802]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
Petro123
ViPRos
они все потокобезопасные :)

Сожалею, но это не отмаз).

му**ло, они все ConcurrentDictionary, Bag, Queue, Satck, ...
3 июл 18, 16:30    [21539805]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
hVostt
ViPRos
Ну все правильно
==> foreach (var e in monitorEventsObjects) Monitor.Enter(e);
установили блокировку (только не для себя, мы не ждем эти события - мы их для других поставили)

тут тоже для себя зеленая дорога (сигнал установлен в конструкторе), а после WaitAll двери захлопываются


всё же тут напрашивается rx )

RXы внутри точно так же сделаны
3 июл 18, 16:31    [21539809]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
hVostt
Member

Откуда:
Сообщений: 16793
ViPRos
RXы внутри точно так же сделаны


это верно, но позволяет не городить огороды, и сосредоточиться на главном
3 июл 18, 16:34    [21539817]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
hVostt
ViPRos
RXы внутри точно так же сделаны


это верно, но позволяет не городить огороды, и сосредоточиться на главном

Хвост!!!!!
Я показал 10 строк кода! Какой еще огород!!!
3 июл 18, 16:36    [21539823]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
И тут это самое главное - запустить параллельно те процессы, которые не претендуют на одни и те же ресурсы.
Эти 5-10 строк кода полностью решают данную задачу.
3 июл 18, 16:38    [21539831]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38643
ViPRos
Petro123
пропущено...

Сожалею, но это не отмаз).

му**ло, они все ConcurrentDictionary, Bag, Queue, Satck, ...

Да?
У них ConcurrentDictionary появился метод Add(.....
Уверен?
"Ты материшься значит не прав"
3 июл 18, 16:39    [21539836]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
Petro123
ViPRos
пропущено...

му**ло, они все ConcurrentDictionary, Bag, Queue, Satck, ...

Да?
У них ConcurrentDictionary появился метод Add(.....
Уверен?
"Ты материшься значит не прав"


Как же ты надоел
ViPRos
hVostt
пропущено...


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

Хвост не горячись - потокобезопасность коллекции делают потокобезопасным только их, а не твой код
все коллекции там потокобезопасные (кроме особых случаев - созданы только для лока)
3 июл 18, 16:45    [21539857]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
hVostt
Member

Откуда:
Сообщений: 16793
ViPRos
Хвост!!!!!
Я показал 10 строк кода! Какой еще огород!!!


ну огород с локами, я просто всегда думаю в контексте разработки, в которой участвует много людей, и с учётом того, что люди приходят/уходят, поэтому, да, огород :)

а также скорее всего, получится организовать конвеер с очередью.
3 июл 18, 16:50    [21539881]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
hVostt
Member

Откуда:
Сообщений: 16793
ViPRos
И тут это самое главное - запустить параллельно те процессы, которые не претендуют на одни и те же ресурсы.
Эти 5-10 строк кода полностью решают данную задачу.


ну ок :) для обсуждения нужна была бы понятная, пусть упрощённая, но полная задача.
3 июл 18, 16:51    [21539887]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
hVostt
а также скорее всего, получится организовать конвеер с очередью.

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

Откуда:
Сообщений: 9739
hVostt
ViPRos
И тут это самое главное - запустить параллельно те процессы, которые не претендуют на одни и те же ресурсы.
Эти 5-10 строк кода полностью решают данную задачу.


ну ок :) для обсуждения нужна была бы понятная, пусть упрощённая, но полная задача.

задача полная m работ n ресурсов …. - в постановка теории расписаний - т.е. самая упрощенная модель
3 июл 18, 16:57    [21539913]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Petro123
Member

Откуда: Загрузочный сектор Москвы (AutoPOI.ru)
Сообщений: 38643
hVostt,
rx не вижу для него.
У rx основа события извне. Причем асинхронные.
А у него обсчёт вариантов.
3 июл 18, 17:52    [21540127]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
Dima T
Member

Откуда:
Сообщений: 14503
ViPRos
Dima T
пропущено...

Я про lock (algroup). Эвенты ждутся после этого лока, а мониторы внутри.
+ выделил нужные строки
пропущено...

Про блокировку AutoResetEvent.WaitAll() ничего не нашел, в хэлпе только про WaitOne()


Ну все правильно
==> foreach (var e in monitorEventsObjects) Monitor.Enter(e);
установили блокировку (только не для себя, мы не ждем эти события - мы их для других поставили)

тут тоже для себя зеленая дорога (сигнал установлен в конструкторе), а после WaitAll двери захлопываются

Я просил код где максимальная нагрузка, а ты старт-стоп показал, самое важное вырезал. Не хочешь обсуждать - твое право, но зачем так тролить? Удачи.
3 июл 18, 20:38    [21540507]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
Dima T
Я просил код где максимальная нагрузка, а ты старт-стоп показал, самое важное вырезал. Не хочешь обсуждать - твое право, но зачем так тролить? Удачи.

Да там обычный код вычислительный (создается множество производственных процессов для производственных структур, которые заблокированы как раз этими строчками и выбирается лучший процесс по заданному критерию при заданных ограничениях), ничего особенного (но объемом в несколько тыщ строк). Код этот очень быстрый и не требует оптимизации. Раньше однопоточная версию устраивала, так как процессов таких надо было выбрать 2-5 миллиона из 10-20. Теперь цифры выросли на порядок и мне надо как то все это вертикально масштабировать, потому решил и этот код распараллелить.
А распараллеливание этого кода не всегда может быть эффективен. Допустим, если производственных мощностей мало и они универсальны, то все техпроцессы будут выполняться на любом из них (или все рабочие универсальны), тогда по любе алгоритм все процессы поставить в очередь это как многозадачность в однопроцессорной машине без IO). Тут распараллеливание только мешает.
Потому самая сложная задача ФОРМИРОВАНИЕ этой очереди (фронта работ) для алгоритма планирования. Это похоже на выталкивание по приоритетам (которые вычисляются в зависимости от производственных структур, структуры работ и т.д. много параметров.
Если коротко, то делается вот что.
1. Кто то разузловывает изделие/проект... (которые в производственных заказах специфированы), находить терминальные ДСЕ, выбирает все альтернативные ТП и из их терминальных (начальных) операций формирует очередь процессов (ТП)
2. Кто то анализирует эту очередь на совместимость по многим политикам
- переналадки (упорядочение для минимизации)
- динамические сборы (печи, гальваника, транспорт,...покраска сушка - совместная обработка)
- технологические сборы (совместная обработка сопрягаемых поверхностей)
--
и выкидывает в фронт работ (оттуда можно их брать для планирования - где будем делать, кто будет, на чем будет, когда будет,... куча ограничений)
3. Кто то эти работы параллельно (раньше был один поток и он успевал) планирует и если что то не так все начинается с п.2
4. После того как какое то изделие/заказ/проект/…. окончательно запланирован идет параллельно запись.

Вот вся задача ооооочень коротоко.
Мы обсуждали часть п.3., которую я переделал недавно.

И я никого не троллил, а просто спросил кое что.
4 июл 18, 01:44    [21541121]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
hVostt
Member

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

Интересно, а человек в этом алгоритме участвует? Может он внести изменения в процессе, или только на конечном или начальном этапах?
4 июл 18, 10:58    [21541755]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

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

Интересно, а человек в этом алгоритме участвует? Может он внести изменения в процессе, или только на конечном или начальном этапах?


Человек управляет алгоритмом через политики, ограничения и параметры процессов.

К сообщению приложен файл. Размер - 57Kb
4 июл 18, 12:25    [21542143]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
hVostt
Member

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

То есть только на начальном этапе. Поправить "в середине" нельзя? Или исправить результат? Я понимаю, что это возможно вообще не требуется.
4 июл 18, 15:45    [21543055]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

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

То есть только на начальном этапе. Поправить "в середине" нельзя? Или исправить результат? Я понимаю, что это возможно вообще не требуется.


Хвост! Там миллионы процессов генерируются (да хоть сотни), что ты там хочешь в интерактиве делать?
Поправить всегда можно, после расчетов видны состояние заказов, указаны заказы с нарушениями директивных сроков и т.д.
Если что то не устраивает, то можешь менять политики, ограничения, параметры и запустить перерасчет.
А так делается по такой схеме.
1. Получили расписание.
2. Работаем и вводим факт.
3. На мониторе диспетчеров видны отклонения.
Когда отклонения не влезают ни в какие ворота (что решает диспетчер или программа по заданным политикам - допустим отклонение в сутки - перерасчет автоматически) инициируется перерасчет.
Перерасчет начинается локально (сначала внутри вышестоящего контекста - для РМ это допустим Участок, для Участка - Пролет, Цех и т.д.) и если можно отклонения компенсировать (т.е. планы других структурных элементов не затрагиваются), то перерасчет заканчивается) и идет эскалация до полной компенсации отклонений. В худшем случае (обычно когда выбраны неадекватные политики - допустим JIT) пересчитывается все расписание.
Потому очень важна скорость расчетов.
А так диспетчер может вручную переставить палки по своему усмотрению (основной режим работы всяких херовых ЕРП) - но я бы дал ему по башке за это.
4 июл 18, 16:22    [21543272]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
После первого расчета расписания получаются так называемые реперные точки (В ВИП.Производстве они называются "Устойчивые к перезапуску процессы". Если при перерасчете эти реперные точки смещены, то по идее я должен оповестить вышестоящие органы - владельцев этих процессов, но пока я это не сделал - нафиг никому ничего не надо.
Это точки обычно - моменты отгрузки покупателю, моменты пополнения запасов (закупки, кооперация,...,), финансовые операции и т.д. вещи связанные с внешней логистикой.
В принципе в серийном и массовом производстве после перерасчета расписание должна удалиться автоматически, оставив только реперные точки.
4 июл 18, 16:29    [21543300]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
hVostt
Member

Откуда:
Сообщений: 16793
ViPRos
Когда отклонения не влезают ни в какие ворота (что решает диспетчер или программа по заданным политикам - допустим отклонение в сутки - перерасчет автоматически) инициируется перерасчет.


Ну отклонения понятно, а переносы? По времени, или использование освободившихся ресурсов. Такое.


ViPRos
А так диспетчер может вручную переставить палки по своему усмотрению (основной режим работы всяких херовых ЕРП) - но я бы дал ему по башке за это.


Я же не знаю, какие у вас регламенты. Часто самые умные и отлаженные процессы не всегда работают в контексте "данного случая".

В целом понятно.


ViPRos
Если при перерасчете эти реперные точки смещены, то по идее я должен оповестить вышестоящие органы - владельцев этих процессов, но пока я это не сделал - нафиг никому ничего не надо.


А этот момент управляется только разработчиком?
4 июл 18, 18:29    [21543828]     Ответить | Цитировать Сообщить модератору
 Re: AutoResetEvent vs Monitor  [new]
ViPRos
Member

Откуда:
Сообщений: 9739
hVostt
ViPRos
Если при перерасчете эти реперные точки смещены, то по идее я должен оповестить вышестоящие органы - владельцев этих процессов, но пока я это не сделал - нафиг никому ничего не надо.


А этот момент управляется только разработчиком?


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