Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
10.09.2003, 11:55
|
|||
|---|---|---|---|
рисуем на канве во втором потоке |
|||
|
#18+
Нород, тут общение на тему потоков у меня навеяло один вопросик. Известно что в дельфи для работы с окном из вторичных потоков предлагается использовать метод synchronyze (могу ошибится в написании). Причины вполне понятны, с окном надо работать в один поток. Возникает вопрос, может быть для этого разруливать критической секцией? Ведь она обеспечивает именно исполнение участка кода одним потоком. У кого какие мнения на этот счет? P.S. Написал и сообразил один недостаток, если под критической секцией вывести мессагу юзеру, то все потоки будут на ней (секции) вставать, пока юзер не отреагирует... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
10.09.2003, 12:20
|
|||
|---|---|---|---|
рисуем на канве во втором потоке |
|||
|
#18+
Предлагаю рассмотреть такой пример: Есть функция RefreshOne. Есть функция RefreshAll. RefreshAll делает какие-то свои действия, потом вызывает RefreshOne, потом завершает делать свои действия. В потоке периодически, в зависимости от внешних факторов (скажем, по таймеру,) вызываются то одна, то другая функция. Пользователь также может вызвать через меню и ту и другую функцию. Как разграничить доступ с помощью критической секции не используя Synchronize? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
10.09.2003, 12:29
|
|||
|---|---|---|---|
рисуем на канве во втором потоке |
|||
|
#18+
Для холста уже есть встроенные методы Lock и UnLock - почитайте о них. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
10.09.2003, 12:44
|
|||
|---|---|---|---|
рисуем на канве во втором потоке |
|||
|
#18+
Понятно, что с Lock / Unlock проблем нет - они позволяют делать вложенные вызовы, а критические секции нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.09.2003, 03:36
|
|||
|---|---|---|---|
рисуем на канве во втором потоке |
|||
|
#18+
Speaker стесняюсь спросить, а на базе чего сделаны эти методы? Честно говоря сейчас специально заглянул в исходник и там именно критические секции. По поводу твоих функций, кто тебе мешает объявить в них критическую секцию и радоваться жизни? Единственное работа с пользователем... нажатие на мышку честно говоря не совсем понятно в какой момент блокировать канву для главного потока? Причем не важно методом Lock или EnterCriticalSection... у кого-нить есть мысли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.09.2003, 10:26
|
|||
|---|---|---|---|
рисуем на канве во втором потоке |
|||
|
#18+
Похоже, я немного заблуждался насчет критических секций, в заблуждение ввело вот это место: Автор статьи писал: procedure LeaveCriticalSection( var lpCriticalSection: TRTLCriticalSection ); stdcall; Эта функция освобождает объект независимо от количества предыдущих вызовов потоком функции EnterCriticalSection . Если имеются другие потоки, ожидающие освобождения секции, один из них становится ее владельцем и продолжает исполнение. Исходя из этого я сделал вывод о невозможности сделать вложенные вызовы, которые необходимы в данном случае. Сейчас посмотрел еще MSDN и SDK Help, ничего про это не сказано. Правда, на мой взгляд, в данном случае это все равно сложнее, чем поставить Synchronize, что, в общем-то, и было сделано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=58&mobile=1&tid=2116938]: |
0ms |
get settings: |
11ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
54ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
2ms |
| others: | 258ms |
| total: | 420ms |

| 0 / 0 |
