Medvedev_A,

Эээ... Как бы указанный способ далеко не самый лучший.

0) ни в коем случае нельзя использовать SendMessage. SendMessageTimeout или аналоги, или postMessage.

1) обновлений может прийти несколько, но видимо показывать есть смысл только одно, последнее. Также обновление бессмысленно показывать, если в данный момент пользователь что-то делает — главный поток может либо вообще ничего не ответить, либо обновление вклинится посреди действий пользователя.
Поэтому в идеале надо обновляться по таймеру или по idle. Читающий поток кладет нужные данные в "гнездо", и возводит флаг, что данные новые, главный поток в очередной раз выходит на iddle, проверяет флаг, и выполняет обновление.
"гнездо" необходимо защищать.

Ну и 100 миллисекунд — это очень часто.
Это порядок времени кадровой развертки телевизора.

Dimitry SibiryakovMasterZiv100 миллисекунд — это очень часто.
Это порядок времени кадровой развертки телевизора.
Бредишь. 100мс это 10fps. Кадровая у телевизора это 60fps.


Я говорил "порядок".

Не 60 FPS, а 25. Это стандартное телевизионное значение.

Basil A. SidorovMasterZivНе 60 FPS, а 25. Это стандартное телевизионное значение.У стандарта SECAM - 50 полукадров.
24 - только в кино.

Ну и чё?
Это меняет что -то?

Basil A. Sidorov,

Не посылать сообщения, а обновлять информацию.
Я ж говорю, тут скорость поступления информации сравнима с максимальной скоростью, с которой глаз что-то может воспринимать, а наверное ещё и мозг что-то успевать сделать должен.

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

Вообще-то потоки специально придуманы, чтобы этого никогда не нужно было делать.
Память у потоков одна и та же, ничего никуда посылать не надо.

zMedvedev_Aа вообще, если я хочу из одного потока послать данные в другой...как это быстрее всего сделать? SendMessage?
Ссылка на общие данные. Контроль доступа - мьютекс.

Между потоками лучше -- критическая секция. В windows.

авторМежду потоками лучше -- критическая секция. В windows.

Критическая секция - вариант мьютекса, где по сути невозможно выполнение какого то кода одновременно несколькими потоками, напр. доступа к данным.

СОГЛАСЕН.
Но в мире Windows мьютекс -- это то, что созадют CreteMutex, а неокрепшие умы не все знают, что есть ещё критические секции, и они -- тоже мьютексы.

авторВ чем будет преимущество по сравнению с "классическим" вариантом мьютекса для данной задачи?

Быстрее. Вообще, если не нужно межпроцессное взаимодействие, то по умолчанию в WinXX надо использовать секции.

авторДа и насчет того, что память у потоков одна и та же... В принципе - да, одни и те же мелкосхемы юзаются
Но логически - это как напишешь. Потоки даже если это одни и те же методы одного и того же класса можно по разному организовать... Напр. никто не запрещает разместить данные непосредственно в самом методе (как один из примеров).

Логически. У потоков. Память. Одна. Даже та, которая в методе одного потока, доступна (и слава Богу!) из другого потока.
Поэтому я и пишу -- ПАМЯТЬ ОДНА. Потому что она одна.

zMasterZiv,

Я запустил 2 независимых потока одного и того же метода. Массив (например) выделен в САМОМ МЕТОДЕ (читай фунуции), нет описателя в "заголовке класса". И ?


Ну и что "И", это такая же память, как и любая другая. Передай ссылку на нее в другой поток как-то — будет доступна.

z,

Ты из недоступности переменной делаешь вывод о недоступности памяти. Это неверно. Память и переменные — разные вещи, к сожалению. Переменная размещается в памяти, и может быть не видна где-то ни непосредственно, ни опосредованно, через ссылки, но даже в этом случае память этой переменной видна и доступна всем потокам данного процесса. А если на эту память, на эту переменную передать другому потоку ссылку, то вот она и будет видна...