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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

начало
                    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

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


у тебя?

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

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

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

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

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

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

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

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

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


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

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


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

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


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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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


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

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

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

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

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