Вверх ↑
Этот топик читают: Гость
Ответов: 195
Рейтинг: 7
#1: 2013-01-19 00:28:44 ЛС | профиль | цитата
Давайте в этой теме соберем все советы и все то что нельзя или не стоит делать в построение схемы Hiasm, ведь бывают случае что допускают ошибки в схемах, которые могут привести к нежелательным ошибкам в программах. Добавляете две схемы в которой есть ошибка и в которой эта ошибка исправлена. оставляйте свои советы основанные на большом опыте работы в среде Hiasm.
P.S.
Надеюсь что эта тема поможет многим в правильном построение схема.
карма: 0

0
Разработчик
Ответов: 26155
Рейтинг: 2127
#2: 2013-01-19 00:45:48 ЛС | профиль | цитата
Про потоки, выдержка из параллельного топика

nesco писал(а):
На будущее, событие onExec происходит в другом потоке приложения, и выполнение его цепи событий никак не совпадает с очередью сообщений главного приложения, те отсутствует синхронизация. Вот почему, запущенная цепь событий другого потока не влияет на очередь сообщений приложения, и приложение не тормозит, если других потоков не сотня, конечно. Чтобы синхронизироваться с очередью сообщений приложения и существует событие onSyncExec. И если таймер дополнительного потока выставил итерацию на точке onExec, то на точке onSyncExec событие появится только тогда, когда закончится вся цепь событий точки onExec, управление будет передано системе, и очередь дойдет до обслуживания очереди сообщений приложения. Все это говорит о том, что событие onSyncExec выполняется синхронно с очередью сообщений приложения, тк обрабатывается именно в этой очереди. Кстати, уничтожать поток крайне желательно именно из точки onSyncExec, если установлено выполнение потока только один раз (FastStop=True), тк поток не уничтожится, а просто остановится, занимаяя ресурсы процессорного времени.Применение элемента Thread ничем практически не отличается от применения элемента MMTimer (в первом случае поток создается приложением, во втором случае -- системой), если только не надо что-то обработать в приложении строго по окончанию действия цепи событий таймерной итерации (к примеру, дать команду на перерисовку формы), но это обязательно будет через некоторое время, необходимое на передачу управления обработчику очереди сообщений приложения, и это время может отличаться от итерации к итерации, те никак не обеспечит точности выдачи итераций


Откуда следует, что давать какое-либо событие визуальному контролу с точки onExec крайне нежелательно (также, как и с точки onTimer MMTimer-a), тк эти точки работают из другого потока, а отрисовка происходит в основном. В момент подачи события, приложение может отрисовываться, что приведет к крэшу программы, что мы, кстати, часто и наблюдаем в некоторых схемах
карма: 22

0
Ответов: 1821
Рейтинг: 168
#3: 2013-01-19 00:46:04 ЛС | профиль | цитата
hin4 писал(а):
Чего не стоит делать...
Использовать EventFromData вместо Memory
карма: 5

1
Голосовали:iarspider
Гость
Ответов: 17029
Рейтинг: 0
#4: 2016-07-08 11:08:19 правка | ЛС | профиль | цитата


Редактировалось 7 раз(а), последний 2021-06-24 08:12:21
карма: 0

0
Ответов: 655
Рейтинг: 18
#5: 2016-07-08 11:54:08 ЛС | профиль | цитата
Неконтролируемо обращаться к ресурсу из разных потоков. Например читать и писать в StrList. Необходимо или использовать критические секции и мьютексы или строить логику ПО так чтобы избежать одновременного использования ресурса.
карма: 0

0
Ответов: 16884
Рейтинг: 1239
#6: 2016-07-10 18:30:47 ЛС | профиль | цитата
Давать советы.
карма: 25
Немного терпения! Дежурный экстрасенс скоро свяжется с Вами!
0
6
Сообщение
...
Прикрепленные файлы
(файлы не залиты)