Перенаправление выполнения с одного потока в другой. Не UI потоки

@Casper-SC · Регистрация: 27.03.2010

Author24 — интернет-сервис помощи студентам

Всем привет. Знает кто-нибудь, как такое можно осуществить? Признаюсь, не сильно копал в эту сторону, но интересует. Можно посмотреть, конечно, исходники последнего дотнета, как там SynchronizationContext в WPF и Windows Forms реализован, но что-то мне подсказывает, что это немного не то. Я и сам копну в эту сторону, если что дельное найду, то отпишу. А если кто уже знает, как это можно сделать, то хотел бы увидеть/узнать.

Зачем это надо? Напрягает ставить локи где ни попадя, чтобы не было с разных потоков одновременных обращений к общему ресурсу.

Psilon · 14.12.2015, 21:37

Casper-SC, насколько я могу судить, винформы запускаются в STAThread, поэтому мы перенаправляем многопоток в основной, чтобы оконная процедура нормально отрабатывала. То есть это костыль для работы конкретно UI, в качестве синхронизации это отстойная идея так выполнять: Slim-мьютексы практически не требуют ресурсов ибо срабатывают на уровне приложения и не производят захвата системного объекта. Перенаправлять вызов в специальный поток намного дольше и имхо менее архитектурно правильно.

@Casper-SC · 14.12.2015, 22:47 **[ТС]**

Psilon, я уже тоже вычитал, что неправильно и т.д. Ну значит не буду заморачиваться этой затеей.

Добавлено через 2 минуты
Psilon, только, зачастую, слим классы синхронизации потоков мне не доступны. На работе .NET 3.5 ибо оживили пылившийся древний проект. Но обещают через пару месяцев перевести всё на .NET 4.5.

Добавлено через 2 минуты

Не по теме:

Это так, к слову. Мне в основном-то реально пригождался пока только AutoResetEvent.

Psilon · 15.12.2015, 00:04

Casper-SC, слимы это то же самое, но они не захватывают системный объект если не нужно.
Вот отличная статья на тему. Использовать Slim стоит всегда, когда только есть возможность. Это аналогично совету использовать List<T> вместо ArrayList. Для существования последнего нет ни единой причины кроме обратной совместимости. Соответственно пользовать не-slim блокировками стоит только если они недоступны из-за старой версии фреймворка.

@kolorotur · 15.12.2015, 00:37

Сообщение от Casper-SC

как такое можно осуществить?

Механизм однопоточных апартаментов в целом реализуется примерно так: где-то запущен отдельный "рабочий" поток, который бесконечно мониторит очередь делегатов и выполняет их по мере получения, а через метод Invoke (например) в эту очередь добавляются делегаты с заданиями.
Приоритеты выполнения прикручиваются по желанию.
Примерно так и реализован STAThread в шарпе.

Сообщение от Psilon

винформы запускаются в STAThread, поэтому мы перенаправляем многопоток в основной, чтобы оконная процедура нормально отрабатывала. То есть это костыль для работы конкретно UI

Это вы механизм поточных апартаментов костылем обложили или перенаправление в гуишный поток?

Psilon · 15.12.2015, 01:05

Сообщение от kolorotur

Это вы механизм поточных апартаментов костылем обложили или перенаправление в гуишный поток?

Ну использования апартаментов я в других случаях я не видел, так что затрудняюсь сказать.
Есть по крайнее мере одно поле, посреди которого пасется по крайней мере одна овца, у которой по крайней мере одна сторона черная ©

@kolorotur · 15.12.2015, 01:17

Сообщение от Psilon

Ну использования апартаментов я в других случаях я не видел

Так COM же. Собственно, у этой идеи оттуда ноги и растут.
Это скорее компромисс, а не костыль

Psilon · 15.12.2015, 01:53

kolorotur, не так много с COM работал, .Net-оберткок вроде System.Managment обычно хватает.

Сообщение от kolorotur

Это скорее компромисс, а не костыль

Ну, не буду возражать против альтернативного именования

@Casper-SC 4432 / 2092 / 404 Регистрация: 27.03.2010 Сообщений: 5,657 Записей в блоге: 1
		1
	Перенаправление выполнения с одного потока в другой. Не UI потоки 14.12.2015, 20:35. Показов 931. Ответов 7 Метки нет (Все метки) Всем привет. Знает кто-нибудь, как такое можно осуществить? Признаюсь, не сильно копал в эту сторону, но интересует. Можно посмотреть, конечно, исходники последнего дотнета, как там SynchronizationContext в WPF и Windows Forms реализован, но что-то мне подсказывает, что это немного не то. Я и сам копну в эту сторону, если что дельное найду, то отпишу. А если кто уже знает, как это можно сделать, то хотел бы увидеть/узнать. Зачем это надо? Напрягает ставить локи где ни попадя, чтобы не было с разных потоков одновременных обращений к общему ресурсу. 0

Psilon Master of Orion 6098 / 4954 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	14.12.2015, 21:37	2
	Casper-SC, насколько я могу судить, винформы запускаются в STAThread, поэтому мы перенаправляем многопоток в основной, чтобы оконная процедура нормально отрабатывала. То есть это костыль для работы конкретно UI, в качестве синхронизации это отстойная идея так выполнять: Slim-мьютексы практически не требуют ресурсов ибо срабатывают на уровне приложения и не производят захвата системного объекта. Перенаправлять вызов в специальный поток намного дольше и имхо менее архитектурно правильно. 1

@Casper-SC 4432 / 2092 / 404 Регистрация: 27.03.2010 Сообщений: 5,657 Записей в блоге: 1
	14.12.2015, 22:47 [ТС]	3
	Psilon, я уже тоже вычитал, что неправильно и т.д. Ну значит не буду заморачиваться этой затеей. Добавлено через 2 минуты Psilon, только, зачастую, слим классы синхронизации потоков мне не доступны. На работе .NET 3.5 ибо оживили пылившийся древний проект. Но обещают через пару месяцев перевести всё на .NET 4.5. Добавлено через 2 минуты Не по теме: Это так, к слову. Мне в основном-то реально пригождался пока только AutoResetEvent. 0

Psilon Master of Orion 6098 / 4954 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	15.12.2015, 00:04	4
	Casper-SC, слимы это то же самое, но они не захватывают системный объект если не нужно. Вот отличная статья на тему. Использовать Slim стоит всегда, когда только есть возможность. Это аналогично совету использовать List<T> вместо ArrayList. Для существования последнего нет ни единой причины кроме обратной совместимости. Соответственно пользовать не-slim блокировками стоит только если они недоступны из-за старой версии фреймворка. 0

@kolorotur 17685 / 12871 / 3365 Регистрация: 17.09.2011 Сообщений: 21,136
	15.12.2015, 00:37	5
	Сообщение от Casper-SC как такое можно осуществить? Механизм однопоточных апартаментов в целом реализуется примерно так: где-то запущен отдельный "рабочий" поток, который бесконечно мониторит очередь делегатов и выполняет их по мере получения, а через метод Invoke (например) в эту очередь добавляются делегаты с заданиями. Приоритеты выполнения прикручиваются по желанию. Примерно так и реализован STAThread в шарпе. Сообщение от Psilon винформы запускаются в STAThread, поэтому мы перенаправляем многопоток в основной, чтобы оконная процедура нормально отрабатывала. То есть это костыль для работы конкретно UI Это вы механизм поточных апартаментов костылем обложили или перенаправление в гуишный поток? 0

Psilon Master of Orion 6098 / 4954 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	15.12.2015, 01:05	6
	Сообщение от kolorotur Это вы механизм поточных апартаментов костылем обложили или перенаправление в гуишный поток? Ну использования апартаментов я в других случаях я не видел, так что затрудняюсь сказать. Есть по крайнее мере одно поле, посреди которого пасется по крайней мере одна овца, у которой по крайней мере одна сторона черная © 0

@kolorotur 17685 / 12871 / 3365 Регистрация: 17.09.2011 Сообщений: 21,136
	15.12.2015, 01:17	7
	Сообщение от Psilon Ну использования апартаментов я в других случаях я не видел Так COM же. Собственно, у этой идеи оттуда ноги и растут. Это скорее компромисс, а не костыль 0

Psilon Master of Orion 6098 / 4954 / 905 Регистрация: 10.07.2011 Сообщений: 14,522 Записей в блоге: 5
	15.12.2015, 01:53	8
	kolorotur, не так много с COM работал, .Net-оберткок вроде System.Managment обычно хватает. Сообщение от kolorotur Это скорее компромисс, а не костыль Ну, не буду возражать против альтернативного именования 0