2013-10-17 19 views
13

Ho bisogno di memorizzare un puntatore univoco per ogni thread a cui si accederà attraverso una macro. Ho pensato di dover risolvere questo problema con un oggetto single_ptr singleton e static_local std :: unique_ptr. Ecco una versione semplificata del codice:C++ 11: GCC 4.8 static_local std :: unique_ptr riferimento undefined

main.cpp

#include <thread> 
#include <vector> 
#include <iostream> 
#include <mutex> 
using namespace std; 

#include "yay.hpp" 

mutex coutMutex; 

void yay(int id) 
{ 
    int* yayPtr = getYay(); 

    // I know this is bad 
    coutMutex.lock(); 
    cout << "Yay nr. " << id << " address: " << yayPtr << endl; 
    coutMutex.unlock(); 
} 

int main() 
{ 
    vector<thread> happy; 
    for(int i = 0; i < thread::hardware_concurrency(); i++) 
    { 
     happy.push_back(thread(yay, i)); 
    } 

    for(auto& smile : happy) 
    { 
     smile.join(); 
    } 
    return 0; 
} 

yay.hpp

#ifndef BE_HAPPY 
#define BE_HAPPY 

#include <memory> 
class Yay 
{ 
    private: 
     static thread_local std::unique_ptr<int> yay; 
     Yay() = delete; 
     Yay(const Yay&) = delete; 
     ~Yay() {} 
    public: 
     static int* getYay() 
     { 
      if(!yay.get()) 
      { 
       yay.reset(new int); 
      } 
      return yay.get(); 
     } 
}; 

#define getYay() Yay::getYay() 

#endif 

yay.cpp

#include "yay.hpp" 

thread_local std::unique_ptr<int> Yay::yay = nullptr; 

Se compilo questo con gcc 4.8 .1:

g++ -std=c++11 -pthread -o yay main.cpp yay.cpp 

ottengo:

/tmp/cceSigGT.o: In function `_ZTWN3Yay3yayE': 
main.cpp:(.text._ZTWN3Yay3yayE[_ZTWN3Yay3yayE]+0x5): undefined reference to `_ZTHN3Yay3yayE' 
collect2: error: ld returned 1 exit status 

Speravo che potrei ottenere ulteriori informazioni dal clangore, ma funziona perfettamente bene con clang 3.4:

clang++ -std=c++11 -pthread -o yay main.cpp yay.cpp 

ed esecuzione del programma si ottiene il risultato che mi aspettavo :

Yay nr. 2 address: 0x7fcd780008e0 
Yay nr. 0 address: 0x7fcd880008e0 
Yay nr. 1 address: 0x7fcd800008e0 
Yay nr. 3 address: 0x7fcd700008e0 
Yay nr. 4 address: 0x7fcd740008e0 
Yay nr. 5 address: 0x7fcd680008e0 
Yay nr. 6 address: 0x7fcd6c0008e0 
Yay nr. 7 address: 0x7fcd600008e0 

non sono sicuro di quello che sto facendo male qui, non è forse possibile avere statica thread_local unique_ptr obj ECTS? Funziona con tipi semplici come puntatori int o 'nudi'.

Edit:

E 'possibile che questo un bug che è legato alla http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55800

Edit2:

Soluzione 1: compilare il file con clangore (yay.cpp)

Soluzione 2 (orribile e non importabile): compilare yay.cpp prima dell'assemblaggio, aggiungere

.globl _ZTWN3Yay3yayE 
_ZTWN3Yay3yayE = __tls_init 

al file di assieme, compilare a oggetto file, il collegamento con il resto

+0

È possibile che la sostituzione del preprocessore di 'getYay()' ti stia rovinando? – Tom

+0

No, non funziona se rimuovo #define e chiama Yay :: getYay() direttamente. – linedot

+0

Nella tua segnalazione di bug mostra una versione molto ridotta del tuo codice e una possibile soluzione alternativa. Forse potresti pubblicarlo come risposta. –

risposta

2

Ho sperimentato questo definendo un ctor do-nothing per Yay in Yay.hpp:

 
- Yay() = delete; 
+ Yay() {} 

Quando l'ho fatto, il messaggio di errore è diventato:

 
/tmp/cc8gDxIg.o: In function `TLS wrapper function for Yay::yay': 
main.cpp:(.text._ZTWN3Yay3yayE[_ZTWN3Yay3yayE]+0x5): undefined reference to `TLS init function for Yay::yay' 

che mi hanno portato a GCC bug 55800. Il bug esiste nelle versioni GCC fino alla 4.8.2 ed è fisso in 4.8.3 e 4.9. Nei thread di discussione che ho trovato sul duplicato GCC bug 59364, è stata presa la decisione di non eseguire il backup della correzione. Pertanto, il tuo assemblatore hack sembra essere l'unica soluzione disponibile fino al passaggio a 4.9.

Problemi correlati