Здравствуйте.У меня возникла проблема с работой потоков на целевой платформе armv5t, (компилятор arm-none-linux-gnueabi, glibc-2.3.6+NPTL). Дело в том, что по непонятным причинам, после захвата mutex поток больше не просыпается, хотя другие потоки по несколько раз уже захватили и освободили этот muntex.
Проблема еще больше заводит меня в тупик, так как этот же самый код работает отлично уже давно на другой платформе (компилятор arm-softfloat-linux-gnu, glibc-2.3.6+linuxthreads).
Пытался собрать glibc-2.5+linuxthreads, но потерпел фиаско, не хватает опыта и знаний.
Может кто-нибудь сталкивался с подобной проблемой, или может подсказать где достать или как собрать glibc-2.5+linuxthreads.
Или хотя бы просветите чем объяснить такое поведение.
Заранее благодарю.
>[оверквотинг удален]
> захвата mutex поток больше не просыпается, хотя другие потоки по несколько
> раз уже захватили и освободили этот muntex.
> Проблема еще больше заводит меня в тупик, так как этот же самый
> код работает отлично уже давно на другой платформе (компилятор arm-softfloat-linux-gnu,
> glibc-2.3.6+linuxthreads).
> Пытался собрать glibc-2.5+linuxthreads, но потерпел фиаско, не хватает опыта и знаний.
> Может кто-нибудь сталкивался с подобной проблемой, или может подсказать где достать или
> как собрать glibc-2.5+linuxthreads.
> Или хотя бы просветите чем объяснить такое поведение.
> Заранее благодарю.Размытое описание проблемы, могу сказать только "где достать или как собрать" glibc со старыми linuxthreads.
Работающие сочетания glibc, ядра и компилятора gcc создаются при помощи кросстулзов;
Самый удобный пакет для создания работающих тулчейнов это http://crosstool-ng.org/. Грубо говоря семейство компиляторов версий от x до y будет работать с глибс версий от а до б, и ну и глибс будет требовать версии ядра.
Спасибо Вова. Сейчас усердно пробую собрать хоть что-нибудь использую указанный тобою инструмент, но не все так гладко...
На счет работоспособности, у меня такое субъективное ошущение, что нет (в NPTL) очереди блокирования примитивов синхронизации, что-то типо того.
Вова, если тебе не сложно, подскажи решение проблемы. Я воспользовался пакетом crosstool-ng. Взял готовый конфигурационный файл для arm-unknown-linux-gnueabi. Заменил в нем библиотеке на glibc-2.5 c linuxthreads. На шаге:
Installing C library headers & start files
[EXTRA] Configuring C libraryу меня ошибка:
configure: error:
[CFG ] *** These critical programs are missing or too old: as ld
[CFG ] *** Check the INSTALL file for required versions.я не знаю, как исправить эту версионную ошибку. Может у меня не правильное сочетание версий компилятора и других утилит...
Заранее спасибо.
> glibc-2.3.6+NPTL).
> Проблема еще больше заводит меня в тупик, так как этот же самый
> код работает отлично уже давно на другой платформе (компилятор arm-softfloat-linux-gnu,
> glibc-2.3.6+linuxthreads).А уж как "заводит меня в тупик" что оно вообще работает при смене linuxthreads на NPTL
>> glibc-2.3.6+NPTL).
>> Проблема еще больше заводит меня в тупик, так как этот же самый
>> код работает отлично уже давно на другой платформе (компилятор arm-softfloat-linux-gnu,
>> glibc-2.3.6+linuxthreads).
> А уж как "заводит меня в тупик" что оно вообще работает при
> смене linuxthreads на NPTLАПИ не менялся, чему там перестать работать?
> АПИ не менялся, чему там перестать работать?Чей API?
Возможные проблемы:
В NPTL у всех потоков один PID а в linuxthreads PID уникален.
Есть и другие ресурсы которые не являются общими linuxthreads, но общие в NPTL.
Есть различия в реакции процесса/потока на сигналы.
Думаю имеет в виду стандартный API для POSIX threads.
Что касается моей проблемы, то ее позволила решить замена функции pthread_mutex_lock (во всей программе), на функциюint mutex_lock(pthread_mutex_t *lock)
{
struct timespec ts;
while(1) {
clock_gettime(CLOCK_REALTIME, &ts);
ts.tv_nsec += 10000000;
if( pthread_mutex_timedlock(lock, &ts) == 0)
return 0;
}
}Плюс добавления небольших usleep в потоки для балансировки время работы потоков в программе.
Просматривая код linuxthreads обнаружил там реализацию очереди для потов, трудно сказать для чего она там применяется, но может быть из-за этого эта библиотека работает гораздо лучше с потоками, в плане из поочередного запуска.
>> АПИ не менялся, чему там перестать работать?
> Чей API?
> Возможные проблемы:
> В NPTL у всех потоков один PID а в linuxthreads PID уникален.
> Есть и другие ресурсы которые не являются общими linuxthreads, но общие в
> NPTL.
> Есть различия в реакции процесса/потока на сигналы.Помогу подытожить: 99%% приложений, работавших с linuxthreads будут работать с реализацией NPTL.