Странности в работе InterlockedExchange в Pascal: разбор необычного поведения кода

Delphi , Компоненты и Классы , Потоки

Странности в работе InterlockedExchange в Pascal: разбор необычного поведения кода

В этой статье мы рассмотрим интересную проблему, связанную с использованием функции InterlockedExchange в многопоточных приложениях на Object Pascal (Delphi), особенно в контексте macOS, а также предложим решения для повышения производительности и надежности вашего кода.

Проблема:

Пользователь han столкнулся с тем, что добавление потоков в приложение не приводит к ожидаемому увеличению скорости работы на macOS, в отличие от Windows и Linux. Более того, на Mac с процессором M-серии многопоточная версия даже работает медленнее однопоточной.

Причина, как выяснилось, крылась в нескольких факторах:

1. Некорректное определение количества процессоров: Функция System.CPUCount возвращала значение 1 на macOS, что приводило к неэффективному использованию ресурсов системы.
2. Неправильная архитектура исполняемого файла: Случайное добавление x86_64 исполняемого файла в ARM инсталлятор.
3. Неэффективное использование InterlockedExchange: Пользователь AlanTheBeast обнаружил, что использование InterlockedExchange в спин-блокировках без задержки (sleep(0)) или с недостаточной задержкой (sleep(1)) может приводить к снижению производительности, особенно на macOS.

Решение:

1. Определение количества процессоров:

   • Проблема: System.CPUCount может возвращать неверное количество процессоров на macOS.

   • Решение:

     • Использовать модуль mtpcpu.pas из Lazarus (путь: lazarus/components/multithreadprocs/mtpcpu.pas) для определения количества логических процессоров.
     • Вносить исправления в локальную копию mtpcpu.pas для корректной работы на конкретных системах (например, изменение _SC_NPROCESSORS_ONLN на _SC_NPROCESSORS_CONF).
     • Реализовать собственную функцию определения количества процессоров, учитывающую особенности macOS.

     Пример кода (адаптированный из решения han):

     function GetSystemThreadCount: integer;
{$IF defined(darwin)}
type PSysCtl =
{$IF FPC_FULLVERSION>=30200}pcint{$ELSE}pchar{$ENDIF};
var mib: array[0..1] of cint;
len: csize_t;
t: cint;
begin
mib[0] := CTL_HW;
mib[1] := HW_NCPU;
len := sizeof(t);
fpsysctl(PSysCtl(@mib), 2, @t, @len, Nil, 0);
Result:=t; end;
{$ELSE}
begin
Result:=1; // Default value for other platforms
end;
{$ENDIF}

   • Альтернативное решение: Предположить фиксированное количество ядер (например, 4), как предложил dbannon, если точное определение затруднено. Однако, это может быть не оптимально для систем с большим количеством ядер.

2. Спин-блокировки и InterlockedExchange:

   • Проблема: Использование InterlockedExchange в спин-блокировках без задержки или с недостаточной задержкой может приводить к "зависанию" процессора и снижению производительности.

   • Решение:

     • Избегать спин-блокировок, если это возможно.
     • Использовать критические секции (TCriticalSection) или другие механизмы синхронизации, предоставляемые Delphi.
     • Если спин-блокировка необходима, добавлять небольшую задержку (Sleep(1)) внутри цикла ожидания, чтобы дать другим потокам возможность получить доступ к процессору. Оптимальное значение задержки может варьироваться в зависимости от платформы и нагрузки.
     • Использовать более продвинутые механизмы синхронизации, такие как TMultiReadExclusiveWriteSynchronizer, как в примере кода от Thaddy.

     Пример использования TCriticalSection:

     var CriticalSection: TCriticalSection;

     procedure ThreadProc(Parameter: Pointer);
     begin
     CriticalSection.Acquire;
     try
     // Критический код, требующий эксклюзивного доступа
     finally
     CriticalSection.Release;
     end;
     end;

     initialization CriticalSection := TCriticalSection.Create;

     finalization CriticalSection.Free;

   • Альтернативное решение: Использовать паттерны, делегирующие задачи контроллерному потоку, чтобы избежать необходимости в интенсивной синхронизации, как предложил Thaddy.

Важные замечания:

• Thread Safety LCL: Необходимо помнить, что LCL (библиотека визуальных компонентов) не является потокобезопасной. Попытки доступа к LCL из разных потоков могут приводить к непредсказуемым результатам и ошибкам.
• Версия FPC: Некоторые решения и примеры кода могут требовать более новых версий FPC (например, 3.3.1 или выше).
• Тестирование: Тщательное тестирование многопоточных приложений на различных платформах и с разной нагрузкой необходимо для выявления и устранения проблем с производительностью и стабильностью.

Вывод:

Многопоточность может значительно повысить производительность приложений, но требует внимательного подхода к синхронизации и управлению ресурсами. Проблемы с InterlockedExchange и некорректным определением количества процессоров на macOS могут приводить к неожиданным результатам. Использование правильных механизмов синхронизации, а также учет особенностей платформы, позволит вам создавать эффективные и надежные многопоточные приложения на Object Pascal.

Создано по материалам из источника по ссылке.

В статье рассматривается проблема низкой производительности многопоточных приложений на macOS из-за особенностей работы `InterlockedExchange` и некорректного определения количества процессоров, а также предлагаются решения для оптимизации кода.

Комментарии и вопросы

Получайте свежие новости и обновления по Object Pascal, Delphi и Lazarus прямо в свой смартфон. Подпишитесь на наш Telegram-канал delphi_kansoftware и будьте в курсе последних тенденций в разработке под Linux, Windows, Android и iOS

:: Главная :: Потоки ::