freepascal.ru

Задался вопросом правильности использования критических секций в потоках.
Хотя вроде и понимаю, надеюсь, но что-то подозрения терзают.

Есть такая тестовая функция потока:

Код: Выделить всё

function TestThread(__Data : Pointer): Integer;
var
  c : integer;
  cs : TRTLCriticalSection;
begin
  c := 0;
  InitCriticalSection(cs);
  while true do
  begin
    EnterCriticalSection(cs);
    Inc(c);
    LeaveCriticalSection(cs);
    if c > 100 then Break;
    Sleep(100);
  end;
  DoneCriticalSection(cs);
  Result := 0;
end;

Запускаем ее так: BeginThread(@TestThread);

Сразу оговорюсь, эта функция не используется в боевых приложениях, а только для теста.

Так вот, если запустить множество таких потоков, с точки зрения правильности работы критических секций, они должны нормально функционировать, не вызывая никаких конфликтов в блокировках между собой?
Есть ли зависимость работы замыканий от числа ядер процессора\потоков процессора? От операционной системы? От архитектуры ЦП?

Существуют ли какие-то особенности или специфика работы множества критических секций в разных, одновременно работающих потоках?

П.С. Столкнулся с тем, что выше описанный тест с потоками на некоторых устройствах под управлением Андроид - вешается при попытке создать\войти\выйти из критической секции.
Все бы было логично, если бы эта ошибка повторялась на большинстве устройств, но она всплывает в единичных случаях, на некоторых моделях устройств.

Использование правильное, но, бессмысленное. Потому как в таком виде, когда КС для каждого потока создается своя, блокировок вообще не должно происходить.
Почему только TThread не использовать? Кстати, BeginThread isMultuthread устанавливает? Чтобы менеджер памяти многопоточным стал.
Что касается зависимости от ядер, ОС и т.п., то она, конечно, есть. Вплоть до компилятора.

Mirage писал(а):Использование правильное, но, бессмысленное. Потому как в таком виде, когда КС для каждого потока создается своя, блокировок вообще не должно происходить.
Почему только TThread не использовать? Кстати, BeginThread isMultuthread устанавливает? Чтобы менеджер памяти многопоточным стал.
Что касается зависимости от ядер, ОС и т.п., то она, конечно, есть. Вплоть до компилятора.

isMultiThread работает, показывает что потоки уже есть.

Естественно пример только для теста и понимания сути проблемы. В боевом приложении секции создаются отдельно и доступ к ним идет из разных потоков.

Вот у меня и возникла основная загвоздка в том, что при одновременном доступе к функциям КС - они (функции) зависают, уходят в ожидание, хотя никаких связей между КС нет.
Значит это проблема ядра ОС, системных библиотек? Потому как при смене устройства (а в месте с ней и сборки ядра) проблема исчезает.

На сколько понимаю, TRTLCriticalSections для ARM архитектуры, это обертка для pthread_mutex_t?

Rang писал(а):Значит это проблема ядра ОС, системных библиотек? Потому как при смене устройства (а в месте с ней и сборки ядра) проблема исчезает.

Это врядли. Думаю, там все оттестировано давно. Скорее проблема где-то в FPC RTL или на стыке.
Чтобы строить более обоснованные предположения надо смотреть как оно реализовано.

Mirage писал(а):

Rang писал(а):Значит это проблема ядра ОС, системных библиотек? Потому как при смене устройства (а в месте с ней и сборки ядра) проблема исчезает.

Это врядли. Думаю, там все оттестировано давно. Скорее проблема где-то в FPC RTL или на стыке.
Чтобы строить более обоснованные предположения надо смотреть как оно реализовано.

Нуу, просто дело в том, что при тесте на нескольких живых устройствах, всех известных эмуляторах из SDK Android, на эмуляторах из Test Lab Самсунгов - все работает идеально, без нареканий.
Тестовая программа одна для всех, скомпилированна на FPC 3.0.0 (последнем).
И проблема зависаний доступа к КС функциям всплыла только на "Galaxy Tab E" (Android 4.4.4), на двух подобных устройствах купленных в разных странах.
Куда точно обращаться даже не знаю, написал в Самсунг - пока молчат.

Я первым делом перепроверил весь свой код связанный с КС. Но даже при отключении функций КС - зависают другие нативные библиотеки (к примеру SDL2).

Проблема разрешилась.

Скачал новый NDK r11, обновил и пересобрал исходники FPC 3.0 и проекта без поддержки FPU. И теперь проблем с зависанием мьютексов на указанных устройствах нет.

Так в чем проблема-то была? В NDK, FPC или FPU?

Mirage писал(а):Так в чем проблема-то была? В NDK, FPC или FPU?

В FPC, а конкретнее в версии 2.6.4 (проект, как оказалось, собирался с этой версией). После того как вычистил все с "0" и пересобрал 3-ю версию FPC - все заработало.

При переключении между NDK r10e и r11 - никаких аномалий не заметил.

Значит не обязательно вставлять критические секции для Android?