Синхронизация потоков

[OmegaBerkut]

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

Задача потоков ДЕЛАТЬ что-то НЕЗАВИСИМО от других

Это по умолчанию ... По сути, мне нужна синхронизация для одновременного доступа к общему ресурсу - UI.
А так, ещё раз объясняю ... Сага о X, Y, Z уже играет мне на руку.
Я пришёл сюда, рассказал, что у меня есть X, что я пытаюсь сделать, что мне нужен Y; мне предложили Z, я согласился-сделал-опроверг, и повторяю - мне таки нужен Y.
При том, везде расставил аргументы; и главный из которых - я не хочу, что бы на интерфейсе висели повторяющиеся операции; это вроде как нормальное желание ...

Сообщение от Пепел Феникса

синхронизация это наоборот, не сообща, а по очереди

Хорошо, может опять терминологию напутал ... Как можно сделать "сообща" ?

[evg_m]

Да. мы уже выяснили что имеем разные понятия о выполняемых задачах.

чтобы начать давать новые рекомендации надо понять ВАШУ задачу(проблему).

итак начнем СНАЧАЛА.
0. есть форма
1. есть много-много потоков. (сколько их ожидается 5..10...100 ???)
2. как МЫ знаем
а) они(потоки) с помощью таймеров ведут некий отсчет. и только ??? (в интересующее нас время работы)
б) при этом обновляют информацию главного окна (время обратного отсчета). и только ???
в) главное окно при этом ведет себя не очень "корректно". A что это означает ??? (если можно без упоминания потоков).

задача: заставить вести это окно корректно. И как это должно выглядить???

Здесь звучала фраза про Invoke в скажем так произвольные моменты времени.
так что некорректно это например:
- раздражающе частое дергание (моргание) окна.
- непрорисовка фона окна при очередном выводе (если только label и нет самого окна)
- ...

это все догадки а что на самом деле?

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

[OmegaBerkut]

evg_m
1) потоков произвольное количество; теоретический предел - Int32.MaxValue

2) есть целая конструкция:
А) "большие" потоки, выполняют задачи, создают потоки Б (у каждого А свой Б), ждут завершение своего потока Б, опять выполняют свою задачу; и так по новой;
Б) "маленькие" потоки, считают оставшееся время до начала выполнения задачи; выводят это время в Label, у каждого Б свой Label.

3) на главном окне несколько Label'ов, ровно столько же, сколько потоков А; во время выполнения потоков Б каждый поток Б выводит информацию на свой собственный Label тогда, когда выполнит расчёт оставшегося времени.

Между собой эти потоки никак не взаимодействуют - из-за этого следующая проблема: в лейбе 1 обновляется время раз в секунду; в лейбе 2 происходит тоже самое - раз в секунду, но с небольшим отставанием/опережением от лейбы 1; так же само у лейбы 3 - произвольный сдвиг от остальных лейбов.
Этот сдвиг может произойти тогда, когда поток А создаёт и запускает свой поток Б; так же, отдельно взятый поток А не может наблюдать за состоянием других не своих потоков Б.

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

[Пепел Феникса]

поток Б должен быть вообще один.

теоретический предел - Int32.MaxValue

он гораздо меньше, память не резиновая, каждый поток это не просто объект Thread.

[OmegaBerkut]

Сообщение от Пепел Феникса

поток Б должен быть вообще один

Каждый поток А имеет своё собственное время ожидания. Я могу сделать так, как вы говорите, но это будет сложнее. Тем более, что потоков А много, и каждый будет пытаться запихнуться в поток Б, что уже наталкивает на мысль о синхронизации ...

Сообщение от Пепел Феникса

он гораздо меньше, память не резиновая, каждый поток это не просто объект Thread

Я это понимаю ... И тем не менее: максимально возможное количество индексируемых элементов в List равно Int32.MaxValue, так что теоретический предел он и есть теоретический ...
На практике такое количество потоков со всеми моими данными займёт примерно 15 гигабайт, что в принципе достижимо на данный момент. Но смысла в этом конечно же нет.

[evg_m]

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

т.е. именно между ПОТОКАМИ, а форма в общем-то работает нормально ( с учетом имеющейся проблемы).

а откуда появилась задача такого синхронного ЗАПУСКА ?
какая в общем-то разница ну запущен поток на пару миллисекунд позже, и ... ?

как не ухищряйся все равно потоки будут стартовать В РАЗНОЕ время (НА ВСЕ Int32.MaxValue потоков просто НЕ ХВАТИТ параллельно работающих ядер процессоров, даже и у Gray или кто-там сейчас есть из супер-компьютеров).
да и работать-то они(потоки Б) полагаю будут независимо?

в лейбе 1 обновляется время раз в секунду; в лейбе 2 происходит тоже самое - раз в секунду, но с небольшим отставанием/опережением от лейбы 1; так же само у лейбы 3 - произвольный сдвиг от остальных лейбов.

это мы уже поняли.
Вопрос ЧЕМУ это мешает? ЗАЧЕМ с этим что-то делать?
если как предлагалось выше обновлять данные скопом, то увидите результат (о том что стартовал какой-то новый поток) на полсекунды позже и что от этого измениться?

[OmegaBerkut]

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

т.е. именно между ПОТОКАМИ, а форма в общем-то работает нормально

Да.

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

а откуда появилась задача такого синхронного ЗАПУСКА ?
какая в общем-то разница ну запущен поток на пару миллисекунд позже, и ... ?

Пользователь будет видеть беспорядочный счёт времени.

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

Задача не критична, но для "красоты" (и для дальнейшего развития) стоит должного внимания

Вот как выглядит морда программы:

Название и количество лейбов опционально.
Проблема визуального характера - секунды отсчитываются (назад если чё) когда получится, как уже было сказано - беспорядочно. Хочу сделать, что бы секунды отсчитывались одновременно.
Цифры после секунд я пока не отбрасываю. Это не пойми что, миллисекунды, или такты, но сейчас это не так важно.

[evg_m]

Пользователь будет видеть беспорядочный счёт времени.

что значит беспорядочный?
смена данных(точнее их отрисовка) в разное время?
некоторые данные "зависают"? так их потокам просто не хватает процессора.

секунды отсчитываются (назад если чё) когда получится, как уже было сказано - беспорядочно

похоже это так и надо бороться именно с ЭТОЙ проблемой.
КАК устроить работу 2*32 потоков на машине с 4-8 ядрами и чтобы ВСЕМ хватило времени. особенно учитывая отсутствие засыпания во всех потоках.
похоже вот он пресловутый X-Y-Z.
OFFTOP. в ссылках на второй странице предлагалось решение слежения за временем запуска чего бы-то ни было БЕЗ потоков с одним единственным таймером.

[OmegaBerkut]

evg_m, никто не собирается запускать 2^31-1 потоков; я кстати ошибся с рассчётами, это не 15 гб, а 5120 тб . Это теоретический предел.
И да, вывод происходит в разное время, я этого пытаюсь избежать.

[evg_m]

И да, вывод происходит в разное время, я этого пытаюсь избежать.

чтобы выводить в одно время, этим заниматься должен кто-то один (форма у нас как раз одна). Но об этом мы уже говорили...

Если же речь все-таки о том что некоторые отсчеты "запаздывают" (точнее замедляют) свой "бег" по сравнению с другими отсчетами (или даже с реальными часами)
ТО это лечиться только уменьшением числа потоков (типа А "наблюдателей за временем") до величины меньше число ядер проца.

Зачем заниматься по сути одним делом(смотреть на часы) десяти и более человек (потоков) если с этим прекрасно справится и один ЕСЛИ...
у него будет СПИСОК контрольных отсечек, с которым он может и будет сверяться с любой заданной периодичностью.
А если еще этот список правильно организовать ...
хотя нет, для визуализации отсчетов все равно нужен будет весь лист отсечек.