2010-11-08 9 views
2

У меня есть кусок кода C/C++, который использует ключевое слово __thread для локального хранилища потоков, но с трудностями с его компиляцией на 64-битном Solaris Sparc с g ++ (версия 4.0.2), в то время как он компилирует и запускает ОК в linux с компилятором g ++ 34. Ниже приведен пример исходного кода:как скомпилировать локальное хранилище потоков (TLS) на 64-битном Solaris sparc с g ++

__thread int count = 0; 

Compiler информация от 'г ++ -dumpversion' команда возвращает '4.0.2' и 'г ++ -dumpmachine' показывает "СПАРК-ВС-solaris2.8. 'uname -a' отображает 'SunOS devsol1 5.9 Generic_118558-26 sun4u sparc SUNW, UltraAX-i2'.

Сообщение об ошибке при запуске сделать с г ++ это: «Ошибка: токарно-локальное хранилище не поддерживается для этой цели», а параметр компилятора я использую

-m64 -g -fexceptions -fPIC  -I../fincad -I/usr/java_1.6.0_12/include -I/usr/java_1.6.0_12/include/solaris -I/opt/csw/gcc4/lib/sparcv9 -I/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.0.2/sparcv9 -I. -I/usr/include -I/usr/include/iso -I/usr/local/include 

Любая помощь очень высоко ценится, как я борется с этим в течение выходных и сталкиваюсь с крайним сроком.

Спасибо, Чарльз

+0

делает http://www.opengroup.org/onlinepubs/009695399/functions/pthread_setspecific.html работу? – Anycorn

ответ

0

Вы могли бы реализовать это переносимым способом с использованием thread_specific_ptr from Boost.Thread.

Если ничего другого, вы должны быть в состоянии решить, как это сделать на Solaris, используя это как ссылку.

+0

'thread_specific_ptr' имеет высокую цену, по сравнению с традиционным TLS (который почти так же быстро, как и доступ к стандартной глобальной/статической переменной). – valdo

2

Вы можете игнорировать специфическое для конкретных файлов хранилище gcc и использовать posix-специфическое хранилище. Он должен работать, и он не является специфичным для gnu. Пример: sun site.

Вот конденсированный пример от ibm. Очевидно, вы хотите использовать несколько потоков.

pthread_key_t tlsKey = 0; 

int main(int argc, char **argv) 
    rc = pthread_key_create(&tlsKey, globalDestructor); 
    /* The key can now be used from all threads */ 

    // Each thread can now use the key: 
    char *myThreadDataStructure; 
    void     *global; 

    myThreadDataStructure = malloc(15);//your data structure 
    pthread_setspecific(tlsKey, myThreadDataStructure); 

    /* Get the data back */  

    global = pthread_getspecific(tlsKey); 


    free (myThreadDataStructure); 
    rc = pthread_key_delete(tlsKey); 
} 
+0

Он отлично работает до сих пор, и на 64-битной среде Linux, и на Solaris. Компилируется как шарм. Все еще ждет завершения теста, но выглядит очень многообещающим. На стороне примечания, как posix-специфическое хранилище сравнивается с gnu с точки зрения производительности. Я не заметил ничего драматичного во время моего теста, но меня интересует этот аспект. Другой комментатор, упомянутый thread_specific_ptr, имеет заметное снижение производительности. – Charles

+0

Честно говоря, я никогда не использовал расширения gnu. Мне было бы интересно узнать, как это работает. –

1

Вы можете попробовать добавить опцию -pthread командной строки г ++: эта опция означает, что в НКУ жаргоне: «сделать все необходимое для POSIX поддержки многопотоковости». Это могло бы разблокировать поддержку для __thread.

Для локального хранилища нити с __thread требуется определенная системная поддержка в компиляторе, но также и в компоновщиках (как статический компоновщик, вызываемый в конце компиляции, так и динамический компоновщик, когда программа выполняется). Я не знаю, поддерживается ли ваша конкретная комбинация (довольно старый g ++ с довольно старым Solaris) (некоторые поисковые запросы показывают, что некоторые люди могут использовать ее с более старым gcc [3.4.3] с более новой Solaris [10]). Если он не поддерживается, вы можете использовать функции POSIX/Single Unix pthread_key_create(), pthread_setspecific() и pthread_getspecific(). Они несколько медленнее и не так удобны, как квалификатор __thread, но, по крайней мере, они работают.

 Смежные вопросы

  • Нет связанных вопросов^_^