Можно ли использовать вместо метода Synchronize критические секции? Есть много потоков, в каждом имеется код, изменяющий прогрессбар, и этот код помещен в критическую секцию. То есть 2 потока не могут одновременно изменить прогрессбар, тогда вроде Synchronize и не к чему?

>То есть 2 потока не могут одновременно изменить прогрессбар, тогда вроде Synchronize и не к чему?

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

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

Через сообщения можно, только не очень удобно, и нарушает принципы ООП.
А любую работу с визуальными компонентами методами VCL можно вести только из главного потока, и критические секции никак не помогут

> _Юрий ©   (10.04.10 23:54) [3]

> Через сообщения можно, только не очень удобно, и нарушает
> принципы ООП.

От чего ж?

--
Regards, LVT.

> только не очень удобно, и нарушает принципы ООП.
очень удобно. плевать на "принципы ООП" если это чего то там нарушает.

> можно вести только из главного потока, и критические секции никак не помогут
почему это? какая разница если цель, не мешать друг другу, достигнута.

Через сообщения можно тому, кто умеет понимать сообщения. ProgressBar умеет, Grid - не умеет. Ну и т.д.

Да и коряво выглядит.

> Да и коряво выглядит.
>

Особенно repeat until false.

> Через сообщения можно тому, кто умеет понимать сообщения.
а если не умеет, то посылать свое сообщение форме, и уже в нем, в обработчике формы (основном потоке) менять что нужно.
ИМХО, но это гораздо лучше, и удобнее синхронизаций из кучи разных потоков. и тормозов нет, т.к. получается "истинное" асинхронное выполнение. (а с синхронизациями или критическими секциями если много одномоментно то они просто станут в очередь...)

> Особенно repeat until false.
ну, это уже особенности данной реализации, а не принцип.

sniknik ©   (11.04.10 10:49) [8]


> ИМХО, но это гораздо лучше, и удобнее синхронизаций из кучи
> разных потоков. и тормозов нет, т.к. получается "истинное"
> асинхронное выполнение. (а с синхронизациями или критическими
> секциями если много одномоментно то они просто станут в
> очередь...)


А SendMessage он натурально воплощение асинхронности. Ерундой не надо болтать.

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

sniknik ©   (11.04.10 12:15) [11]


> используй post, я так и делаю


И потенциально нарываешься на проблемы. В твоем конкретном случае проблем может и не быть, но рекомендовать такой способ, как замену критических секций и Synchronize в многопоточных приложениях, по меньшей мере, опрометчиво.


> в чем проблема то?


Проблема в последователях Ивана Кулибина, обощающих свои частные случаи велосипедов с квадратными колесами на транспорт целиком.

> Leonid Troyanovsky ©   (11.04.10 00:26) [4]
>
>
> От чего ж?
>

"Дырявая абстракция".
Впрочем, это само по себе не столь страшно, чтобы отказываться от такого метода в принципе. Решение, имхо, надо принимать исходя из того, насколько эта система (эта ее часть) будет расширяемая \ изменяемая.
Если предполагается долгий цикл жизни приложения, то лучше сделать нормально, а не через одно место, если это "разовая" утилита, то сойдет

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

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

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

> Нужно учитывать, что очереди выборки сообщений ограничены
> по размеру


Че ????

> Игорь Шевченко ©   (11.04.10 14:53) [15]
> > Нужно учитывать, что очереди выборки сообщений ограничены
> > по размеру Че ????


Не знал?

Демо ©   (11.04.10 15:16) [16]

Ладно я не знал, еще и Рихтер, зараза, утверждает прямо противоположное.

Чего вас сегодня на бред пробивает, день такой или что ?

> Чего вас сегодня на бред пробивает, день такой или что ?


There is a limit of 10,000 posted messages per message queue. This limit should be sufficiently large. If your application exceeds the limit, it should be redesigned to avoid consuming so many system resources. To adjust this limit, modify the following registry key.
HKEY_LOCAL_MACHINE
  SOFTWARE
     Microsoft
        Windows NT
           CurrentVersion
              Windows
                 USERPostMessageLimit
The minimum acceptable value is 4000.

http://msdn.microsoft.com/en-us/library/ms644944(VS.85).aspx


> Ладно я не знал, еще и Рихтер, зараза, утверждает прямо
> противоположное.


Игорь, можно цитату из Рихтера?

> Игорь, можно цитату из Рихтера?


Куда ж без цитаты-то:

"В 16-битной Windows каждая задача имеет собственную очередь сообщений...По умолчанию очередь позволяет хранить до 8 сообщений. Изменить ее можно вызовом SetMessageQueue. В Win32 API тоже есть такая функция, но необходимости в ней нет, так как сообщения хранятся в виде связанного списка и ограничения на их количество не существует".

Джеффри Рихтер, Windows для профессионалов, Microsoft Press, 1995

> Игорь Шевченко ©   (11.04.10 18:22) [19]
> > Игорь, можно цитату из Рихтера?Куда ж без цитаты-то:"В
> 16-битной Windows каждая задача имеет собственную очередь
> сообщений...По умолчанию очередь позволяет хранить до 8
> сообщений. Изменить ее можно вызовом SetMessageQueue. В
> Win32 API тоже есть такая функция, но необходимости в ней
> нет, так как сообщения хранятся в виде связанного списка
> и ограничения на их количество не существует".Джеффри Рихтер,
>  Windows для профессионалов, Microsoft Press, 1995


Скорее всего это касается исключительно Windows 95 (ну может 98).

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

Демо ©   (11.04.10 18:31) [20]

Был неправ, извиняюсь.

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


> Скорее всего это касается исключительно Windows 95 (ну может
> 98).


Это касается Windows NT в первую очередь.

здесь max имеет тип WORD 0..65535, а как быть если у меня max может принимать бОльшие значения?

> tippa ©   (11.04.10 21:11) [22]
> SendMessage(H, PBM_SETRANGE, 0,MAKELPARAM(min, max));здесь
> max имеет тип WORD 0..65535, а как быть если у меня max
> может принимать бОльшие значения?


Для творчества достаточно широкие возможности.

1. Передаются 2 параметра - WParam и LParam, а это уже Int64
2. Для SendMessage можно передавать указатель на исходные данные (например, Pointer на структуру данных - record, либо прямо на объект - Self)
3. В любом случае (в том числе и PostMessage) можно передавать указатель на структуру (Перед передачей - New(pMyrecord) ), в обработчике же уничтожать (Например - Dispose(PMyRecord(Msg.WParam)) ).
4. Существует сообщение WM_COPYDATA, но его дучше использовать для межпроцессного взаимодействия.

как сказал Крош из смешариков - "слишком сложно чтобы быть правдой".

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

> Демо ©   (11.04.10 22:20) [23]
>
> 1. Передаются 2 параметра - WParam и LParam, а это уже Int64

Хм. Когда эти параметры стали 64-х битными? Я что-то прозевал?

> Хм. Когда эти параметры стали 64-х битными? Я что-то прозевал?


Хм. неужели я разучился числа складывать? Если собрать в одну структуру LongInt(LParam) и LongInt(WParam), то не получим LongLong(Int64)?




Может я что-то не понимаю?

> Демо ©   (12.04.10 02:08) [26]
>
>
> > Хм. Когда эти параметры стали 64-х битными? Я что-то прозевал?
>
>
>
> Хм. неужели я разучился числа складывать? Если собрать в
> одну структуру LongInt(LParam) и LongInt(WParam), то не
> получим LongLong(Int64)?
>

Ты не разучился складывать. :)
Это я разучился понимать :(

P.S. Но уж автор скорее всего вообще ничего не поймет.

во как просто