Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Synchronize и критические секции

Страницы: 1 2 >
tippa © (2010-04-10 07:44:00)
Можно ли использовать вместо метода Synchronize критические секции? Есть много потоков, в каждом имеется код, изменяющий прогрессбар, и этот код помещен в критическую секцию. То есть 2 потока не могут одновременно изменить прогрессбар, тогда вроде Synchronize и не к чему?

tippa (2010-04-12 08:45:00) [1]
во как просто
SendMessage(H, PBM_SETRANGE32, min,max);

Германн (2010-04-12 02:18:00) [2]

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

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

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

Демо (2010-04-12 02:08:00) [3]

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

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

type LONGLONG = Int64; _LARGE_INTEGER = record case Integer of 0: ( LowPart: DWORD; HighPart: Longint); 1: ( QuadPart: LONGLONG); end;

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

Германн (2010-04-12 01:51:00) [4]

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

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

sniknik (2010-04-11 23:22:00) [5]
как сказал Крош из смешариков - "слишком сложно чтобы быть правдой".

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

Демо (2010-04-11 22:20:00) [6]

> 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, но его дучше использовать для межпроцессного взаимодействия.

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

Игорь Шевченко (2010-04-11 19:06:00) [8]
Демо © (11.04.10 18:31) [20]

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

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

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

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

Демо (2010-04-11 18:31:00) [9]

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

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

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

Игорь Шевченко (2010-04-11 18:22:00) [10]

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

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

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

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

Демо (2010-04-11 17:36:00) [11]

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

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

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

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

Игорь Шевченко (2010-04-11 16:09:00) [12]
Демо © (11.04.10 15:16) [16]

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

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

Демо (2010-04-11 15:16:00) [13]

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

Не знал?

Игорь Шевченко (2010-04-11 14:53:00) [14]

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

Че ????

Демо (2010-04-11 13:50:00) [15]
Как всегда - для применения инструмента нужно знать точно, что делаешь.

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

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

_Юрий (2010-04-11 13:26:00) [16]

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

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

Игорь Шевченко (2010-04-11 12:49:00) [17]
sniknik © (11.04.10 12:15) [11]

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

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

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

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

sniknik (2010-04-11 12:15:00) [18]
> А SendMessage он натурально воплощение асинхронности. Ерундой не надо болтать.
используй post, я так и делаю, в чем проблема то? просто идею "обкакать"? взяли неудачный пример и считаем что все в нем "гвоздями прибито", ничего менять нельзя. и на этом основании говорим метод - дерьмо.

Игорь Шевченко (2010-04-11 11:27:00) [19]
sniknik © (11.04.10 10:49) [8]

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

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

sniknik (2010-04-11 10:50:00) [20]
> Особенно repeat until false.
ну, это уже особенности данной реализации, а не принцип.

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »