Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Зависание программы и TThread

Модерирует : ShIvADeSt

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2

Открыть новую тему     Написать ответ в эту тему

Dronton2

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
asutp2
Если ваш код не вызывал проблем мильён раз, но вы не знаете, как Дельфи работает с памятью, то нет никакой гарантии, что в мильён первый раз не выскочит ошибка (например, при повышении нагрузки на процессор или на другом процессоре). Где эмбаркадеровцы пишут о том, выводят ли они переменные из кэша при входе/выходе в критическую зону? Я этого не нашёл.

Всего записей: 460 | Зарегистр. 27-06-2005 | Отправлено: 17:15 02-12-2016
asutp2

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Dronton2, ошибка нехватки ресурсов/памяти/свопа и т.д. может выскочить в любой момент в программе на любом языке. Это стандартная ситуация, которая может произойти, для обработки подобных ситуаций в делфи и существуют try/except/finally.
 
С другой стороны модель памяти, раз это вам так важно, можно условно считать черным ящиком. Насколько она фрагментируется, как часто сжимаются кучи и т.д. мы можем не знать, поэтому просто минимизируем выделение/освобождение динамической памяти. Для минимизации фрагментации памяти минимизируем использование .Create и .Free, используем фиксированные массивы (либо выделенные один раз участки памяти, которые уничтожаются при завершении работы) и так далее в этом же духе.
 
Лично я делал стресс тесты работы с памятью в делфи путем 24-х часового прогона создания/удаления участков памяти произвольного размера . Замерял скорость этих операций и количество ошибок. Результаты показали, что если нет утечек, то даже при такой интенсивной работе с памятью менеджер памяти делфи работает достойно и его можно использовать даже в критических приложениях.

Всего записей: 791 | Зарегистр. 22-10-2004 | Отправлено: 17:43 02-12-2016
Dronton2

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
т.к. у нас генерится нативный код  

C++ тоже генерит нативный код, но модель памяти у него прописана в стандарте.
Атомарность переменных от нативности кода, насколько я знаю, не зависит. И запись 8-байтной переменной на 32-битном x86 может прерваться другим потоком в нативном коде, т.к. у процессора нет соответствующей хардварной операции.
И современные процессоры могут за один такт выполнять несколько инструкций нативного ассемблера, выполняя их в произвольном порядке.
Ну, и выше я привёл цитату о том, что Дельфи забивает на пересечение данными кэш-лайна, при котором на x86 атомарность теряется. Но это - частное мнение. А Эмбаркадеро молчит?
Поправьте, если я неправ.

Всего записей: 460 | Зарегистр. 27-06-2005 | Отправлено: 17:44 02-12-2016
asutp2

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Dronton2
 

Цитата:
 Где эмбаркадеровцы пишут о том, выводят ли они переменные из кэша при входе/выходе в критическую зону? Я этого не нашёл.

 
я правильно понимаю, что мы ведем речь об атрибуте [volatile] ?
 
 
 
Добавлено:

Цитата:
И современные процессоры могут за один такт выполнять несколько инструкций нативного ассемблера, выполняя их в произвольном порядке.  

ну не совсем в произвольном порядке а понимаешь я указал записать в регистр, а потом сравнить - то именно в таком порядке и выполнится, а не произвольно. надеюсь ты согласен с этим?

Всего записей: 791 | Зарегистр. 22-10-2004 | Отправлено: 17:48 02-12-2016
Dronton2

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

Вы меня неправильно поняли. Модель памяти в языке программирования - не то, как память выделяется/освобождается или как данные размещаются в куче, а то, как разные потоки совместно используют разделяемые между ними данные. Это атомарность, happens-before, работа с кэшем процессора, критические секции и описание того, что гарантирует комилятор в этом плане программисту.
 
Добавлено:

Цитата:
я правильно понимаю, что мы ведем речь об атрибуте [volatile] ?  

volatile, как я понимаю, принципиально не оптимизируется и не помещается ни в регистры, ни в кэш. А вот другие переменные, которые используются в критических секциях? Один поток записал переменную (в кэш?). Другой поток на другом ядре - прочитал эту же переменную, но откуда - из своего кэша?

Цитата:
ну не совсем в произвольном порядке  
согласен. Не совсем в произвольном. Но порядок выполнения может меняться, например, от наличия данных в кэше.

Всего записей: 460 | Зарегистр. 27-06-2005 | Отправлено: 18:12 02-12-2016
LadyOfWood

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
И запись 8-байтной переменной на 32-битном x86 может прерваться другим потоком в нативном коде, т.к. у процессора нет соответствующей хардварной операции.  

На этот случай есть Interlocked функции.  

Цитата:
критические секции

Критические секции, как и теже Interlocked функции отношения к Delphi по большому счету не имеют, это часть Windows API.

Всего записей: 620 | Зарегистр. 16-09-2003 | Отправлено: 19:28 02-12-2016
ShIvADeSt



Moderator
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Нашел в Интернете
Android does not support Application.ProcessMessages by design, so it cannot be implemented in the LCL.


----------
И создал Бог женщину... Существо получилось злобное, но забавное...

Всего записей: 3956 | Зарегистр. 29-07-2003 | Отправлено: 03:35 05-12-2016
Dronton2

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Критические секции, как и теже Interlocked функции отношения к Delphi по большому счету не имеют, это часть Windows API.  
А в остальных операционных системах что делать? Писать всё заново? Вот Steepe_Hare наткнулся, что Application.ProcessMessages под Андроидом не работает.
С другой стороны, обмен сообщениями между объектами - более универсальная вещь. Код программы становится проще, разные части программы - менее зависимы друг от друга. А если приходится переписывать чужую программу? Использовал ли мой предшественник критические секции и Interlocked там, где нужно? И использовал ли их вообще?

Всего записей: 460 | Зарегистр. 27-06-2005 | Отправлено: 12:45 05-12-2016
asutp2

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Dronton2, а как быть с тем фактом, что сообщения между объектами не имеют 100% гарантии доставки?

Всего записей: 791 | Зарегистр. 22-10-2004 | Отправлено: 13:29 05-12-2016
Dronton2

Full Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
сообщения между объектами не имеют 100% гарантии доставки?  
Где об этом можно почитать?

Всего записей: 460 | Зарегистр. 27-06-2005 | Отправлено: 13:39 05-12-2016
asutp2

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Dronton2, для виндов - в Windows SDK. У сообщений разный приоритет, все зависит от загрузки системы. Да и это можно проверить самому, тестовой прогой, которая пошлет например 10 млн сообщений. Дойдут до получателя не все.

Всего записей: 791 | Зарегистр. 22-10-2004 | Отправлено: 14:04 05-12-2016
Steepe_Hare



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ShIvADeSt

Цитата:
Нашел в Интернете
Android does not support Application.ProcessMessages by design, so it cannot be implemented in the LCL.

 
Источник?

Всего записей: 1162 | Зарегистр. 27-10-2001 | Отправлено: 15:47 05-12-2016
LadyOfWood

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
А в остальных операционных системах что делать? Писать всё заново?

Это основные примитивы синхронизации, они должны быть во всех ОС. Но точно скажу тока за Windows.

Всего записей: 620 | Зарегистр. 16-09-2003 | Отправлено: 23:33 05-12-2016
ShIvADeSt



Moderator
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Steepe_Hare
http://forum.lazarus.freepascal.org/index.php?topic=17244.0


----------
И создал Бог женщину... Существо получилось злобное, но забавное...

Всего записей: 3956 | Зарегистр. 29-07-2003 | Отправлено: 02:38 06-12-2016
asutp2

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ShIvADeSt, по ссылке речь идет о реализации application.processmessages в лазарусе. У меня под руками его нет, поэтому реализацию посмотреть не могу.
 
Что же касается делфи, то там реализация application.processmessages следующая (berlin 10.1 upd 2):
 
procedure TApplication.ProcessMessages;
var
  AppService: IFMXApplicationService;
begin
  if TPlatformServices.Current.SupportsPlatformService(IFMXApplicationService, AppService) then
    while AppService.HandleMessage do { loop };
end;
 

Всего записей: 791 | Зарегистр. 22-10-2004 | Отправлено: 09:56 06-12-2016
zealotfan



Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Steepe_Hare
По именно твоей теме есть отличный вебинар на русском. ТАм даже пример по-моему подходит https://www.youtube.com/watch?v=21vf5H54a8U&index=7&list=PLNexYoB7XRWZv-6QviwJzdRKthKuBR_dG&t=3050s

Всего записей: 234 | Зарегистр. 25-02-2016 | Отправлено: 11:36 09-12-2016
Steepe_Hare



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
zealotfan
 
спасибо

Всего записей: 1162 | Зарегистр. 27-10-2001 | Отправлено: 12:32 09-12-2016
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2

Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Зависание программы и TThread


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru