Могу ли я быть уверен, что код, который я пишу, всегда выполняется в одном и том же потоке? - PullRequest
1 голос
/ 13 ноября 2008

Я обычно работаю с однопоточными приложениями и вообще никогда не задумывался о работе с потоками. Мое понимание того, как все работает - что, безусловно, может быть неверным, - это то, что, пока мы всегда имеем дело с однопоточным кодом (то есть без разветвлений или чего-то подобного), он всегда будет выполняться в одном потоке.

Это предположение верно? У меня есть нечеткая идея, что библиотеки / фреймворки пользовательского интерфейса могут порождать свои собственные потоки для обработки графического интерфейса пользователя (что объясняется тем фактом, что диспетчер задач Windows говорит мне, что мое «однопоточное» приложение на самом деле работает на 10 потоках), но я я предполагаю, что это не должно повлиять на меня?

Как это относится к COM? Например, если бы я должен был создать экземпляр COM-компонента в моем коде; и что COM-компонент записывает некоторую информацию в местоположение на основе потоков (например, с использованием System.Threading.Thread.GetData), сможет ли мое приложение получить эту информацию?

Итак, в итоге:

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

  2. Если этот однопоточный код должен был создать экземпляр COM-компонента, который хранит некоторую информацию в расположении на основе потоков, может ли он быть подобным образом извлечен из любого другого места?

Ответы [ 2 ]

2 голосов
/ 13 ноября 2008

Пользовательский интерфейс обычно имеет противоположное ограничение (к сожалению): он однопоточный, и все должно происходить в этом потоке.

Самый простой способ проверить, всегда ли вы находитесь в одном потоке (например, для функции), - это установить целочисленную переменную в -1 и иметь функцию проверки, например (например, вы в C #):

void AssertSingleThread()
{
   if (m_ThreadId < 0) m_ThreadId = Thread.CurrentThread.ManagedThreadId;
   Debug.Assert(m_ThreadId == Thread.CurrentThread.ManagedThreadId);
}

Это говорит:

Я не понимаю вопроса № 1, правда. Зачем хранить в расположении на основе потоков, если ваша цель - иметь глобальную область видимости?

Что касается второго вопроса, большая часть кода COM выполняется в одном потоке и, чаще всего, в потоке, в котором выполняется обработка сообщений вашего интерфейса пользователя, - это потому, что большая часть кода COM разработана для совместимости с VB6, который является однопоточным.

Причина, по которой ваша программа имеет около 10 потоков, заключается в том, что как Windows (если вы используете некоторые из ее функций, например, порты завершения или некоторые таймеры), так и CLR (например, для GC или, опять же, некоторые типы таймеров). ) может создавать потоки в вашем пространстве процессов (технически любая программа с достаточным количеством привилегий тоже может).

0 голосов
/ 13 ноября 2008

Подумайте о том, чтобы в вашем mainThread работала модель с одним классом dataStore, в который все потоки могут читать и записывать свои переменные экземпляра. Это позволит избежать многих проблем, которые могут возникнуть при доступе к потокам по всему магазину.

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

Java обрабатывает это, позволяя вам объявлять переменную или метод синхронизированным, предоставляя доступ только одному потоку за раз.

Я полагаю, что некоторые объекты .NET имеют определенные методы Lock и Synchronized, но я знаю не более того.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...