Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. Mobile and Embedded
  4. QObject creating in one thread using in other

QObject creating in one thread using in other

Scheduled Pinned Locked Moved Mobile and Embedded
13 Posts 4 Posters 6.1k Views
  • 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.
  • T Offline
    T Offline
    tobias.hunger
    wrote on last edited by
    #3

    Passing signals back and forth between threads is thread save, accessing member variables of an object from another thread is not. So your application behaves exactly as expected.

    1 Reply Last reply
    0
    • D Offline
      D Offline
      DenisKormalev
      wrote on last edited by
      #4

      Tobias, but simple reading member (without any operatinos from other threads on it) of object from another thread should not crash app.

      1 Reply Last reply
      0
      • D Offline
        D Offline
        danilocesar
        wrote on last edited by
        #5

        [quote author="Denis Kormalev" date="1287682429"]Tobias, but simple reading member (without any operatinos from other threads on it) of object from another thread should not crash app.[/quote]

        You can you a QMutex to solve the writing part, afair...

        <a href="http://www.danilocesar.com">Danilo Cesar Lemes de Paula</a>
        Software Engineer

        1 Reply Last reply
        0
        • D Offline
          D Offline
          DenisKormalev
          wrote on last edited by
          #6

          danilocesar, it is part what I am saying of. As I think author doesn't have race conditions, but has some problems with accessing members. So I think source will be really good to help him.

          1 Reply Last reply
          0
          • T Offline
            T Offline
            tobias.hunger
            wrote on last edited by
            #7

            Denis: Sure, but how do you guarantee that no other thread does some writing somewhere without using a mutex or something similar?

            1 Reply Last reply
            0
            • D Offline
              D Offline
              danilocesar
              wrote on last edited by
              #8

              [quote author="Tobias Hunger" date="1287687383"]Denis: Sure, but how do you guarantee that no other thread does some writing somewhere without using a mutex or something similar?[/quote]

              You don't, however you need to understand/know what your code is doing =)

              I believe we will help better when sriky27 post some code...

              <a href="http://www.danilocesar.com">Danilo Cesar Lemes de Paula</a>
              Software Engineer

              1 Reply Last reply
              0
              • D Offline
                D Offline
                DenisKormalev
                wrote on last edited by
                #9

                Tobias, of course there are no guarantee, but I think that question is not about mutexes. Let's wait for authors response.

                1 Reply Last reply
                0
                • D Offline
                  D Offline
                  danilocesar
                  wrote on last edited by
                  #10

                  [quote author="Tobias Hunger" date="1287687383"]Denis: Sure, but how do you guarantee that no other thread does some writing somewhere without using a mutex or something similar?[/quote]

                  I thought this message was for me =/

                  <a href="http://www.danilocesar.com">Danilo Cesar Lemes de Paula</a>
                  Software Engineer

                  1 Reply Last reply
                  0
                  • S Offline
                    S Offline
                    sriky27
                    wrote on last edited by
                    #11

                    Hi,

                    Thanks for the responses there I am currently stripping my project related content and creating a simple application to present here. To explain what I am doing.

                    My objective of creating and starting a new thread was to improve startup of my process, the thread purely constructs an QObject and returns it to the main thread. The thread dies after that.
                    I believe I should not have any race conditions there. No one else is trying to access the object.

                    -Sriky

                    1 Reply Last reply
                    0
                    • T Offline
                      T Offline
                      tobias.hunger
                      wrote on last edited by
                      #12

                      A commonly used trick to improved perceived startup performance is to create some objects using a singleshot QTimer. That way the complexity of multithreading can be avoided in some cases. Maybe that would be applicable to your setup, too.

                      1 Reply Last reply
                      0
                      • S Offline
                        S Offline
                        sriky27
                        wrote on last edited by
                        #13

                        well i have tried it, i have two objects which take about 2 sec for constructing each of them, i wanted improve on it, so that the objects gets constructed in parallel.

                        -Sriky

                        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