0

I'm using a pthread_barrier_t from C/C++ on my code to synchronize 3 different threads. When I'm using the Debug, through gdb, it works just fine, but when I run the binary directly from the board, all 3 threads get stuck on the pthread_barrier_wait. It seems that the barrier can't see that all of the 3 threads are there.

I'm cross-compiling the code to ARM using Ubuntu 14.10, with g++4.9, arm-linux-gnueabihf. The board is a BBB similar with TI AM3352 and Debian 8.

the code is thread 1

case stRecv :
    pthread_barrier_wait(&IonEntCommBarrier[client]); 
    if(IonFillAnswer[client])
      state = stSend;
    else
      state = stStop;
    break;

thread 2

case stRecv :
    pthread_barrier_wait(&IonEntCommBarrier[client]); 
    if(IonFillAnswer[client])
      state = stSend;
    else
      state = stStop;
    break;

thread 3 

case stRecv           :
    IonEntCommData[client].RequestLen = Recv(client, EthernetObj->getRXBufAddr(client));
    IonFillAnswer[client] = false;

    if(IonEntCommData[client].RequestLen > 1) {
      IonFillAnswer[client] = true;
      state = stSend;   // Msg Ok!
    } else {
      EthernetObj->setEthernetFlag(client, ETH_START);
    }

    if(IonEntCommData[client].RequestLen <= 1) break;
    IonEntToutTSyssec[client] = TIMEOUT_S_ION;    // Timer zerado
    pthread_barrier_wait(&IonEntCommBarrier[client]); 
    break;

i`m initializing the barrier using 

pthread_barrier_init(&IonEntCommBarrier[client],NULL,3);

Anyone knows what its going on here?

PS: Other functions of the same library are working well, like pthread_mutex, just the barrier doesn't.

caf
  • 233,326
  • 40
  • 323
  • 462
Filipe Meireles
  • 1
  • Are you ensuring with synchronisation primitives that the threads cannot try to wait on the barrier until the `pthread_barrier_init()` call has definitely returned? – caf Aug 21 '15 at 01:04
  • Is it possible that there is an error in your code that is masked when you debug? Verify that in each of your calls to pthread_barrier_wait the value of client is the same. If they are keep looking otherwise it is likely you have something that doesn't get initialised properly in your code and that when you use gdb the issue is masked. – Michael Shaw Aug 21 '15 at 16:43
  • Multithreading issues that go away in the debugger usually indicate some sort of race condition. When do you call `pthread_barrier_init(3)`? Are you sure the barrier is initialized before any thread tries to use it? – Filipe Gonçalves Aug 21 '15 at 21:02

0 Answers0