Сообщение Re[13]: Как оптимизировать выполнения 10000 параллельных зад от 08.08.2016 16:20
Изменено 08.08.2016 16:31 Sharov
Здравствуйте, LWhisper, Вы писали:
LW>Здравствуйте, Sharov, Вы писали:
S>>Не работал с этой библиотекой и этим примитвом. Поверхостный просмотр github'а выдал такой комментарий для метода wait (что логично):
S>>
LW>Да, для метода Task.Run().Wait(). В моём случае — Task.Run(async delegate) без Wait.
LW>Поэтому, либо что-то не так с кодом автора (но он пишет умные книжки про асинки), либо в моей реализации, но она как раз использует его логику.
LW>В принципе, банальная логика подсказывает, что мы не можем вызывать Monitor.Enter/Exit из разных потоков. Следовательно, они вызываются в одном потоке. Следовательно, он блокируется и висит в очереди на блокировке. Как это может работать иначе — не знаю. Но выше по треду, рекомендовали именно такой вариант. Вот я и пытаюсь разобраться — чем он лучше обыкновенного ManualResetEvent.Wait().
Все вроде так. А лучше тем, что сдает поток обратно в пул, т.е. поток подхватывает другую задачу и т.д. Потом проверет статус event'а. Я понял это так, ибо дело с этой библиотекой и примитивами не имел.
S>>Вроде бы WhenAll (ContinueWhenAll), который появился в версии фреймворка 4.5. Я использую библиотеку ParallelExtensionsExtras, который дополняет функциональность 4.0.
LW>WhenAll действительно запустит продолжение в новом потоке, но если текущий повиснет на блокировке, мы получим ровну ту же самую ситуацию с висящим потоком, который не возвращается в пул.
Ну так переходите на async io, для всех блокирующих io вызов еще со времен второго фреймворка сущ. асинхронные аналоги. А к асинхронным callback'ам можно и task'и подвязать. Больше Вам ничего не поможет. Все эти однопоточные серверы c10k типа tornado (python) или node.js построены вокруг асинхронных io операций.
LW>Здравствуйте, Sharov, Вы писали:
S>>Не работал с этой библиотекой и этим примитвом. Поверхостный просмотр github'а выдал такой комментарий для метода wait (что логично):
S>>
S>>Synchronously waits for this event to be set. This method may block the calling thread.
LW>Да, для метода Task.Run().Wait(). В моём случае — Task.Run(async delegate) без Wait.
LW>Поэтому, либо что-то не так с кодом автора (но он пишет умные книжки про асинки), либо в моей реализации, но она как раз использует его логику.
LW>В принципе, банальная логика подсказывает, что мы не можем вызывать Monitor.Enter/Exit из разных потоков. Следовательно, они вызываются в одном потоке. Следовательно, он блокируется и висит в очереди на блокировке. Как это может работать иначе — не знаю. Но выше по треду, рекомендовали именно такой вариант. Вот я и пытаюсь разобраться — чем он лучше обыкновенного ManualResetEvent.Wait().
Все вроде так. А лучше тем, что сдает поток обратно в пул, т.е. поток подхватывает другую задачу и т.д. Потом проверет статус event'а. Я понял это так, ибо дело с этой библиотекой и примитивами не имел.
S>>Вроде бы WhenAll (ContinueWhenAll), который появился в версии фреймворка 4.5. Я использую библиотеку ParallelExtensionsExtras, который дополняет функциональность 4.0.
LW>WhenAll действительно запустит продолжение в новом потоке, но если текущий повиснет на блокировке, мы получим ровну ту же самую ситуацию с висящим потоком, который не возвращается в пул.
Ну так переходите на async io, для всех блокирующих io вызов еще со времен второго фреймворка сущ. асинхронные аналоги. А к асинхронным callback'ам можно и task'и подвязать. Больше Вам ничего не поможет. Все эти однопоточные серверы c10k типа tornado (python) или node.js построены вокруг асинхронных io операций.
Re[13]: Как оптимизировать выполнения 10000 параллельных зад
Здравствуйте, LWhisper, Вы писали:
LW>Здравствуйте, Sharov, Вы писали:
S>>Не работал с этой библиотекой и этим примитвом. Поверхостный просмотр github'а выдал такой комментарий для метода wait (что логично):
S>>
LW>Да, для метода Task.Run().Wait(). В моём случае — Task.Run(async delegate) без Wait.
LW>Поэтому, либо что-то не так с кодом автора (но он пишет умные книжки про асинки), либо в моей реализации, но она как раз использует его логику.
LW>В принципе, банальная логика подсказывает, что мы не можем вызывать Monitor.Enter/Exit из разных потоков. Следовательно, они вызываются в одном потоке. Следовательно, он блокируется и висит в очереди на блокировке. Как это может работать иначе — не знаю. Но выше по треду, рекомендовали именно такой вариант. Вот я и пытаюсь разобраться — чем он лучше обыкновенного ManualResetEvent.Wait().
Все вроде так. А лучше тем, что сдает поток обратно в пул, т.е. поток подхватывает другую задачу и т.д. Потом проверит статус event'а. Я понял это так, ибо дело с этой библиотекой и примитивами не имел.
S>>Вроде бы WhenAll (ContinueWhenAll), который появился в версии фреймворка 4.5. Я использую библиотеку ParallelExtensionsExtras, который дополняет функциональность 4.0.
LW>WhenAll действительно запустит продолжение в новом потоке, но если текущий повиснет на блокировке, мы получим ровну ту же самую ситуацию с висящим потоком, который не возвращается в пул.
Ну так переходите на async io, для всех блокирующих io вызов еще со времен второго фреймворка сущ. асинхронные аналоги. А к асинхронным callback'ам можно и task'и подвязать. Больше Вам ничего не поможет. Все эти однопоточные серверы c10k типа tornado (python) или node.js построены вокруг асинхронных io операций.
LW>Здравствуйте, Sharov, Вы писали:
S>>Не работал с этой библиотекой и этим примитвом. Поверхостный просмотр github'а выдал такой комментарий для метода wait (что логично):
S>>
S>>Synchronously waits for this event to be set. This method may block the calling thread.
LW>Да, для метода Task.Run().Wait(). В моём случае — Task.Run(async delegate) без Wait.
LW>Поэтому, либо что-то не так с кодом автора (но он пишет умные книжки про асинки), либо в моей реализации, но она как раз использует его логику.
LW>В принципе, банальная логика подсказывает, что мы не можем вызывать Monitor.Enter/Exit из разных потоков. Следовательно, они вызываются в одном потоке. Следовательно, он блокируется и висит в очереди на блокировке. Как это может работать иначе — не знаю. Но выше по треду, рекомендовали именно такой вариант. Вот я и пытаюсь разобраться — чем он лучше обыкновенного ManualResetEvent.Wait().
Все вроде так. А лучше тем, что сдает поток обратно в пул, т.е. поток подхватывает другую задачу и т.д. Потом проверит статус event'а. Я понял это так, ибо дело с этой библиотекой и примитивами не имел.
S>>Вроде бы WhenAll (ContinueWhenAll), который появился в версии фреймворка 4.5. Я использую библиотеку ParallelExtensionsExtras, который дополняет функциональность 4.0.
LW>WhenAll действительно запустит продолжение в новом потоке, но если текущий повиснет на блокировке, мы получим ровну ту же самую ситуацию с висящим потоком, который не возвращается в пул.
Ну так переходите на async io, для всех блокирующих io вызов еще со времен второго фреймворка сущ. асинхронные аналоги. А к асинхронным callback'ам можно и task'и подвязать. Больше Вам ничего не поможет. Все эти однопоточные серверы c10k типа tornado (python) или node.js построены вокруг асинхронных io операций.