Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Special Interest Groups
  3. C++ Gurus
  4. Question about QThread and how thread work in general.
Forum Updated to NodeBB v4.3 + New Features

Question about QThread and how thread work in general.

Scheduled Pinned Locked Moved Solved C++ Gurus
32 Posts 9 Posters 9.4k Views 6 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • F Factao

    @kshegunov Then I didn't understand the meaning of your first intervention. I apoligize

    @kshegunov and @jsulm . I'm using slots and signals in order to command the worker thread, but this last one, when not doing a specific task, is within a loop, constantly reading value from a servo and saving them. Since there is a lot of variable that change frequently, emitting a signal for every one of them might slow the application down, due to how signal/slot work.

    @CP71 Thanks, this is the example that I was looking for. To summarize, I'm locking when a thread is using a function that use a specific value and nothing more. So making a specific and short function that only return or modify the value is a good way to avoid traffic while multiple thread are accessing the same thing.
    edit: After trying it, now I see that there is an issue with the function other than void, I can't do:

    int m_something;// private element of class
    int class::returnSomething() const
    {
    mutex.lock()
    return m_something;
    mutex.unlock()
    };
    

    If I'm doing that:

    int class::returnSomething() const
    {
    mutex.lock();
    int something(m_something);
    mutex.unlock();
    return something;
    }
    

    Is this what we are trying to do here? From what I understand, our goal Is to prevent two thread to access the same data simultaneously, not the same function.

    So, to be sure of getting it, here is a summarize of what I get out of this topic:
    We need to lock data when a thread is accessing it to be sure that the data going to stay where it should be during the operation. If we don't do it, a thread from another core could possibly "steal" the data that we need and create a little problems in our program.

    Is this approximately true? Or do I miss something?

    kshegunovK Offline
    kshegunovK Offline
    kshegunov
    Moderators
    wrote on last edited by
    #23

    @Factao said in Question about QThread and how thread work in general.:

    I'm using slots and signals in order to command the worker thread, but this last one, when not doing a specific task, is within a loop, constantly reading value from a servo and saving them. Since there is a lot of variable that change frequently, emitting a signal for every one of them might slow the application down, due to how signal/slot work.

    The signal-slot connections work very similarly to how you'd serialize access with a mutex, as a matter of fact they do exactly that - serialize access to the event loop through a mutex. So unless you can prove that emission and handling of signals is a bottleneck, that concern is moot. The big advantage, however, is that thread access is defined strictly and clearly for each QObject involved, so it makes for convenient and fast coding.

    Read and abide by the Qt Code of Conduct

    CP71C 1 Reply Last reply
    2
    • kshegunovK kshegunov

      @Factao said in Question about QThread and how thread work in general.:

      I'm using slots and signals in order to command the worker thread, but this last one, when not doing a specific task, is within a loop, constantly reading value from a servo and saving them. Since there is a lot of variable that change frequently, emitting a signal for every one of them might slow the application down, due to how signal/slot work.

      The signal-slot connections work very similarly to how you'd serialize access with a mutex, as a matter of fact they do exactly that - serialize access to the event loop through a mutex. So unless you can prove that emission and handling of signals is a bottleneck, that concern is moot. The big advantage, however, is that thread access is defined strictly and clearly for each QObject involved, so it makes for convenient and fast coding.

      CP71C Offline
      CP71C Offline
      CP71
      wrote on last edited by CP71
      #24

      Hi @kshegunov,
      I'm Qt developer only for few years, so I’m quite newbie ;)
      Is there difference using signals&slots or direct method between threads with different priority?
      I think yes but I’m not sure.
      Thanks

      J.HilkJ 1 Reply Last reply
      0
      • CP71C CP71

        Hi @kshegunov,
        I'm Qt developer only for few years, so I’m quite newbie ;)
        Is there difference using signals&slots or direct method between threads with different priority?
        I think yes but I’m not sure.
        Thanks

        J.HilkJ Offline
        J.HilkJ Offline
        J.Hilk
        Moderators
        wrote on last edited by
        #25

        @CP71 the main difference is, that your signal argument, if it is a struct or class, needs to have a copy constructor.

        Where as with direct mutex lock, you simply lock the data block, access it and unlock it.


        Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


        Q: What's that?
        A: It's blue light.
        Q: What does it do?
        A: It turns blue.

        CP71C 1 Reply Last reply
        2
        • J.HilkJ J.Hilk

          @CP71 the main difference is, that your signal argument, if it is a struct or class, needs to have a copy constructor.

          Where as with direct mutex lock, you simply lock the data block, access it and unlock it.

          CP71C Offline
          CP71C Offline
          CP71
          wrote on last edited by CP71
          #26

          @J.Hilk
          Thank you,
          yes this I know, my question was incomplete, sorry.
          but I’m thinking about response time.

          1 Reply Last reply
          0
          • F Offline
            F Offline
            Factao
            wrote on last edited by
            #27

            Well, thank you everyone, thank you. I think that we can conclude this topic. Once again, thank you.

            @CP71 said in Question about QThread and how thread work in general.:

            I think I could learn from you ;)

            If you need help on a subject that is more mechanical or mathematical, don't hesitate, I will be more than happy to help you back.

            CP71C 1 Reply Last reply
            1
            • F Factao

              Well, thank you everyone, thank you. I think that we can conclude this topic. Once again, thank you.

              @CP71 said in Question about QThread and how thread work in general.:

              I think I could learn from you ;)

              If you need help on a subject that is more mechanical or mathematical, don't hesitate, I will be more than happy to help you back.

              CP71C Offline
              CP71C Offline
              CP71
              wrote on last edited by
              #28

              @Factao
              Sure, count on it.
              Thanks

              1 Reply Last reply
              0
              • F Factao

                @kshegunov Then I didn't understand the meaning of your first intervention. I apoligize

                @kshegunov and @jsulm . I'm using slots and signals in order to command the worker thread, but this last one, when not doing a specific task, is within a loop, constantly reading value from a servo and saving them. Since there is a lot of variable that change frequently, emitting a signal for every one of them might slow the application down, due to how signal/slot work.

                @CP71 Thanks, this is the example that I was looking for. To summarize, I'm locking when a thread is using a function that use a specific value and nothing more. So making a specific and short function that only return or modify the value is a good way to avoid traffic while multiple thread are accessing the same thing.
                edit: After trying it, now I see that there is an issue with the function other than void, I can't do:

                int m_something;// private element of class
                int class::returnSomething() const
                {
                mutex.lock()
                return m_something;
                mutex.unlock()
                };
                

                If I'm doing that:

                int class::returnSomething() const
                {
                mutex.lock();
                int something(m_something);
                mutex.unlock();
                return something;
                }
                

                Is this what we are trying to do here? From what I understand, our goal Is to prevent two thread to access the same data simultaneously, not the same function.

                So, to be sure of getting it, here is a summarize of what I get out of this topic:
                We need to lock data when a thread is accessing it to be sure that the data going to stay where it should be during the operation. If we don't do it, a thread from another core could possibly "steal" the data that we need and create a little problems in our program.

                Is this approximately true? Or do I miss something?

                KroMignonK Offline
                KroMignonK Offline
                KroMignon
                wrote on last edited by
                #29

                @Factao said in Question about QThread and how thread work in general.:

                int m_something;// private element of class
                int class::returnSomething() const
                {
                mutex.lock()
                return m_something;
                mutex.unlock()
                };

                Hi Factao, just give you a little hint abour QMutex usage, the easiest way to deal with QMutex, is to use QMutexLocker, to avoid having mutex lock when leaving function:

                int class::returnSomething() const
                {
                    QMutexLocker lock(&mutex);
                    Q_UNUSED(lock) // just to remove warnings
                    return m_something;
                };
                

                At function begin, mutex will be locked, and when lock is distroyed (by living function) mutex will be released.
                This will avoid having deadlocks!

                But as writen in other comments, using Signals/Slots mechanisme to exhange information between object in different thread is the most easiest way. You don't have to deal with mutex. The disadvantage is that will have shadow copies of your data, so if there are big amonth of data, this could be a problem.

                Hope this will help you

                It is an old maxim of mine that when you have excluded the impossible, whatever remains, however improbable, must be the truth. (Sherlock Holmes)

                kshegunovK 1 Reply Last reply
                5
                • KroMignonK KroMignon

                  @Factao said in Question about QThread and how thread work in general.:

                  int m_something;// private element of class
                  int class::returnSomething() const
                  {
                  mutex.lock()
                  return m_something;
                  mutex.unlock()
                  };

                  Hi Factao, just give you a little hint abour QMutex usage, the easiest way to deal with QMutex, is to use QMutexLocker, to avoid having mutex lock when leaving function:

                  int class::returnSomething() const
                  {
                      QMutexLocker lock(&mutex);
                      Q_UNUSED(lock) // just to remove warnings
                      return m_something;
                  };
                  

                  At function begin, mutex will be locked, and when lock is distroyed (by living function) mutex will be released.
                  This will avoid having deadlocks!

                  But as writen in other comments, using Signals/Slots mechanisme to exhange information between object in different thread is the most easiest way. You don't have to deal with mutex. The disadvantage is that will have shadow copies of your data, so if there are big amonth of data, this could be a problem.

                  Hope this will help you

                  kshegunovK Offline
                  kshegunovK Offline
                  kshegunov
                  Moderators
                  wrote on last edited by kshegunov
                  #30

                  @KroMignon said in Question about QThread and how thread work in general.:

                  will have shadow copies of your data

                  For implicitly shared types (Qt types) - shallow copies, which may or may not, depending on the use, become deep copies.

                  @CP71 said in Question about QThread and how thread work in general.:

                  Hi @kshegunov,
                  Is there difference using signals&slots or direct method between threads with different priority?

                  Priority has nothing to do with anything. The thread priority is a hint to the scheduler how large a time slot to dispense.

                  Read and abide by the Qt Code of Conduct

                  K 1 Reply Last reply
                  2
                  • kshegunovK kshegunov

                    @KroMignon said in Question about QThread and how thread work in general.:

                    will have shadow copies of your data

                    For implicitly shared types (Qt types) - shallow copies, which may or may not, depending on the use, become deep copies.

                    @CP71 said in Question about QThread and how thread work in general.:

                    Hi @kshegunov,
                    Is there difference using signals&slots or direct method between threads with different priority?

                    Priority has nothing to do with anything. The thread priority is a hint to the scheduler how large a time slot to dispense.

                    K Offline
                    K Offline
                    Konstantin Tokarev
                    wrote on last edited by
                    #31

                    @kshegunov said in Question about QThread and how thread work in general.:

                    Priority has nothing to do with anything. The thread priority is a hint to the scheduler how large a time slot to dispense.

                    Actually, in some operating systems (e.g. in Linux via sched_setscheduler) it's possible to change scheduler for particular thread to real-time (in Linux SCHED_FIFO or SCHED_RR). Real-time thread have static priorities which has deeper effect on time slots than dynamic ("nice") priorities

                    (QThread::IdlePriority is internally implemented via SCHED_IDLE on Linux, other options use default scheduler with dynamic priorities)

                    kshegunovK 1 Reply Last reply
                    0
                    • K Konstantin Tokarev

                      @kshegunov said in Question about QThread and how thread work in general.:

                      Priority has nothing to do with anything. The thread priority is a hint to the scheduler how large a time slot to dispense.

                      Actually, in some operating systems (e.g. in Linux via sched_setscheduler) it's possible to change scheduler for particular thread to real-time (in Linux SCHED_FIFO or SCHED_RR). Real-time thread have static priorities which has deeper effect on time slots than dynamic ("nice") priorities

                      (QThread::IdlePriority is internally implemented via SCHED_IDLE on Linux, other options use default scheduler with dynamic priorities)

                      kshegunovK Offline
                      kshegunovK Offline
                      kshegunov
                      Moderators
                      wrote on last edited by
                      #32

                      Perhaps, but I don't see an implication for the case of signal-slot connections vs direct synchronization ... at the end of the day the former still uses a mutex to serialize access to the queued events ...

                      Read and abide by the Qt Code of Conduct

                      1 Reply Last reply
                      0

                      • Login

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • Users
                      • Groups
                      • Search
                      • Get Qt Extensions
                      • Unsolved