Необходимы объяснения по доступности объектов из разных потоков

@FaceHoof · Регистрация: 21.04.2014

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

Здравствуйте.
Есть простой код:

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
namespace WindowsFormsApplication1
{
    public partial class Form1 : Form
    {
        private Object thisLock = new Object();
        short[] arrTEST = null;
        int a = 0;
 
        public Form1()
        {
            InitializeComponent();           
        }
 
        private void WorkCompleted(short[] ar)
        {
            arrTEST = ar;
        }
 
        private void Work()
        {
            short[] aryusBuffer = new short[10];
            a = 1;
            WorkCompleted(aryusBuffer);
            
        }
 
        private void button1_Click(object sender, EventArgs e)
        {
            Thread thr;
            lock (thisLock)
            {
                thr = new Thread(Work);
                thr.Start();
            }  
        }
    }
}

Я не понимаю, почему в этом коде не происходит ошибки. Метод Work запускается в отдельном потоке. И в нём задаётся значение переменных, которые созданы не в нём. Но если я попытаюсь в методе Work или WorkCompleted обратиться, на пример, к какому-нибудь TextBox на форме, то ожидаемо получу ошибку.
Так почему вообще существует такая разница? Почему к переменным я могу запросто обращаться, а к каким-то объектам на форме - нет?

@OwenGlendower · 10.07.2017, 15:54

FaceHoof, потому что у элементов формы есть привязка к потоку который их создал (thread affinity), а у обычных значений переменных такой привязки нет. Она нужна потому что цикл обработки сообщений Windows работает в конкретном потоке. То есть данная связь просходит на уровне ОС, а не .NET. Отсюда следует простой вывод что данное ограничение верно для любого языка программирования.

@hoolygan · 10.07.2017, 15:55

Потому что UI - это тоже поток. И если Вы зададите 2 потока с одной и той же переменной - то будут артифакты с присвоениями, когда 2 потока будут решать кому первому обновить переменную. Поэтому разработчики Net решили, что нечего потоку вторгаться в UI поток. Да и не нужно это. Проблема Thread-ов в криворукости, а не во фреймворке. 99,99% кода, что наблюдаю на форуме, когда запихивают в поток - можно сделать с помощью Task-ов. Благо они работают еще с 3.5 версии Фреймворка. А Thread-ы - уже давным давно почили в лабах студентов, и понимании, что Task-и строятся именно на Thread-ах.
Вывод - если не понимаете многопоточности - не прибегайте к использованию непонятных конструкций, особенно, если касаетесь разработки UI.

@OwenGlendower · 10.07.2017, 17:21

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

Потому что UI - это тоже поток.

Я бы немного по другому сказал. За UI отвечает свой поток с циклом обработки сообщений (message loop).

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

Поэтому разработчики Net решили, что нечего потоку вторгаться в UI поток.

Скорее это решили разработчики Windows, а разработчки .NET были вынуждены двигаться в их колее.

@FaceHoof · 11.07.2017, 11:07 **[ТС]**

hoolygan, хотите сказать, что Thread - это старьё, о котором стоит вспоминать только в достаточно редких и специфичных случаях? А чтобы "долгий" процесс не вызывал ощущение зависшей программы лучше всего пользоваться Task? Я правильно понял?

@hoolygan · 11.07.2017, 11:26

FaceHoof,

Ну не совсем так - Task-и работают в пуле потоков. Пул потоков основан на Thread-ах. Т.е. Thread - это базовая величина во всем асинхронном программировании. Это база, как табличка умножения. Но редко кто пользуется табличкой умножения для расчета диф. уравнений. Поэтому для новых проектов Microsoft рекомендует и настаивает на использовании тасков. А потоки - остались на уровне обучения, потому что иначе таски никто бы не понял бы, как и почему они работают.
Но есть спецефические проекты, которые работают без UI, и там - вполне себе оправдано использование потоков. Даже больше скажу - у нас на проекте мы активно используем шаблон, основанный на интерфейсе IAsuncResult, потому что разрабатывался он (проект) довольно давно, и теперь приходится его поддерживать, и + работать должен на win XP, так что работу с async/await невозможно использовать.
Таких задач море, но при работе с UI использование потоков нужно делать очень осторожно, постоянно думая о MethodInvoker, и прочих прелестях устаревшей архитектуры.

Новые блоги и статьи Все статьи Все блоги /
Автоматическое создание документа при проведении другого документа Maks 29.03.2026 Реализация из решения ниже выполнена на нетиповых документах, разработанных в конфигурации КА2. Есть нетиповой документ "ЗаявкаНаРемонтСпецтехники" и нетиповой документ "ПланированиеСпецтехники". В. . .	Настройка движения справочника по регистру сведений Maks 29.03.2026 Решение ниже реализовано на примере нетипового справочника "ТарифыМобильнойСвязи" разработанного в конфигурации КА2, с целью учета корпоративной мобильной связи в коммерческом предприятии. . . .	Автозаполнение реквизита при выборе элемента справочника Maks 27.03.2026 Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. При выборе "Спецтехники" (Тип Справочник. Спецтехника), заполняется. . .	Сумматор с применением элементов трёх состояний. Hrethgir 26.03.2026 Тут. https:/ / fips. ru/ EGD/ ab3c85c8-836d-4866-871b-c2f0c5d77fbc Первый документ красиво выглядит, но без схемы. Это конечно не даёт никаких плюсов автору, но тем не менее. . . всё может быть. . .
Автозаполнение реквизитов при создании документа Maks 26.03.2026 Программный код из решения ниже размещается в модуле объекта документа, в процедуре "ПриСозданииНаСервере". Алгоритм проверки заполнения реализован для исключения перезаписи значения реквизита,. . .	Команды формы и диалоговое окно Maks 26.03.2026 1. Команда формы "ЗаполнитьЗапчасти". Программный код из решения ниже на примере нетипового документа "ЗаявкаНаРемонтСпецтехники" разработанного в конфигурации КА2. В качестве источника данных. . .	Кому нужен AOT? DevAlt 26.03.2026 Решил сделать простой ланчер Написал заготовку: dotnet new console --aot -o UrlHandler var items = args. Split(":"); var tag = items; var id = items; var executable = args;. . .	Отправка уведомления на почту при создании или изменении элементов справочника Maks 24.03.2026 Программная отправка письма электронной почты на примере типового справочника "Склады" в конфигурации БП3. Перед реализацией необходимо выполнить настройку системной учетной записи электронной. . .

@OwenGlendower Администратор 18298 / 14222 / 5368 Регистрация: 17.03.2014 Сообщений: 28,900 Записей в блоге: 1
	10.07.2017, 15:54
	FaceHoof, потому что у элементов формы есть привязка к потоку который их создал (thread affinity), а у обычных значений переменных такой привязки нет. Она нужна потому что цикл обработки сообщений Windows работает в конкретном потоке. То есть данная связь просходит на уровне ОС, а не .NET. Отсюда следует простой вывод что данное ограничение верно для любого языка программирования. 1

@hoolygan 360 / 287 / 76 Регистрация: 21.06.2016 Сообщений: 1,115
	10.07.2017, 15:55
	Потому что UI - это тоже поток. И если Вы зададите 2 потока с одной и той же переменной - то будут артифакты с присвоениями, когда 2 потока будут решать кому первому обновить переменную. Поэтому разработчики Net решили, что нечего потоку вторгаться в UI поток. Да и не нужно это. Проблема Thread-ов в криворукости, а не во фреймворке. 99,99% кода, что наблюдаю на форуме, когда запихивают в поток - можно сделать с помощью Task-ов. Благо они работают еще с 3.5 версии Фреймворка. А Thread-ы - уже давным давно почили в лабах студентов, и понимании, что Task-и строятся именно на Thread-ах. Вывод - если не понимаете многопоточности - не прибегайте к использованию непонятных конструкций, особенно, если касаетесь разработки UI. 1

@FaceHoof 113 / 100 / 68 Регистрация: 21.04.2014 Сообщений: 1,420
	11.07.2017, 11:07 [ТС]
	hoolygan, хотите сказать, что Thread - это старьё, о котором стоит вспоминать только в достаточно редких и специфичных случаях? А чтобы "долгий" процесс не вызывал ощущение зависшей программы лучше всего пользоваться Task? Я правильно понял? 0

@hoolygan 360 / 287 / 76 Регистрация: 21.06.2016 Сообщений: 1,115
	11.07.2017, 11:26
	FaceHoof, Ну не совсем так - Task-и работают в пуле потоков. Пул потоков основан на Thread-ах. Т.е. Thread - это базовая величина во всем асинхронном программировании. Это база, как табличка умножения. Но редко кто пользуется табличкой умножения для расчета диф. уравнений. Поэтому для новых проектов Microsoft рекомендует и настаивает на использовании тасков. А потоки - остались на уровне обучения, потому что иначе таски никто бы не понял бы, как и почему они работают. Но есть спецефические проекты, которые работают без UI, и там - вполне себе оправдано использование потоков. Даже больше скажу - у нас на проекте мы активно используем шаблон, основанный на интерфейсе IAsuncResult, потому что разрабатывался он (проект) довольно давно, и теперь приходится его поддерживать, и + работать должен на win XP, так что работу с async/await невозможно использовать. Таких задач море, но при работе с UI использование потоков нужно делать очень осторожно, постоянно думая о MethodInvoker, и прочих прелестях устаревшей архитектуры. 1