0

I know "printf" is standard-c and should be deterministic. But when run in Qt I see a more non-deterministic response(clock cycles). Could this be due to Qt adding some "pork" to its response?

I have multiple threads that make call to function that uses a mutex. When one thread enters it set a switch so the others can't until it is done. Things appeared to work ok for acouple seconds and then threads appeared to be killed off from 10 to 1 thread. So I tried adding a delay: (k=k+1: no help), then (looping k=k+1: no help), (usleep works), and so does (printf) work at creating a random delay and allowing all threads to continue running.

void CCB::Write(int iThread)
{
    static bool bUse = false;
    bool bDone = false;
    char cStr[20];
    int posWrite;// = *m_posWrite;  // issue of posWrite be altered with next extrance
    long k = 0;
    long m = 0;
    m_threadCount++;

    while(bDone == false){

        if(bUse == false){
            bUse = true;
            posWrite = *m_posWrite;

            memcpy(m_cmMessageCB + posWrite, &m_cmMessageWrite, sizeof(typeCanMessage));

            memset(cStr, '\0', 20);
            memcpy(cStr, (m_cmMessageCB + posWrite)->cMessage, 11); //fails: every 20

            *m_posWrite = *m_posWrite + 1;
            if(*m_posWrite == m_iNBufferLength)
                *m_posWrite = 0;

            bDone = true;
            bUse = false;

        }else if(bUse == true){
            //why are threads being killed ?
    //            printf("T%d_%d ", iThread, m_threadCount);//non-deterministic value ?
            usleep(1);//non-deterministic value
            //k++;//delay of a couple clock cycles was not enough

            /*
            for(k = 0; k < iThread * 100; k++){//deterministic and fails to resolve thread problem
                m++;
            }
            */
        }
    }
}
jdl
  • 6,151
  • 19
  • 83
  • 132
  • Define "non-deterministic"! – Oliver Charlesworth Aug 23 '13 at 15:18
  • If you're observing undefined behavior, it's most likely the fault of your input arguments. Please include them. – Jacob Aug 23 '13 at 15:19
  • 3
    Can you provide an [SSCCE](http://sscce.org/) that demonstrates this behavior and what you expect the output to be? As presented we just don't have enough information. – Shafik Yaghmour Aug 23 '13 at 15:19
  • 4
    There's no mutex in this code, just a `bool` value that's shared between threads. This will **not** produce valid synchronization. Use a real mutex. – Pete Becker Aug 23 '13 at 15:33
  • 1
    @Jacob - it's really not possible to observe undefined behavior. You can observe **bad** behavior, but undefined behavior simply means that the language definition doesn't say what happens; the result can be that the code does exactly what the person who wrote it expects it to do. – Pete Becker Aug 23 '13 at 15:48
  • The bottom line thing I am trying to build is if one entrace to the buffer is in use then use another entrance up to 4 of them. So I still have to deal with threads in suspension. – jdl Aug 23 '13 at 15:50
  • `printf()` is a pit of CPU cycles, especially as it goes to stdout. Consider using sprintf() to form the string s[80]. See if problems go away. If they do, add a direct puts(s). – chux - Reinstate Monica Aug 24 '13 at 01:55

0 Answers0