Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. Is QList thread-safe for certain operations?
Forum Updated to NodeBB v4.3 + New Features

Is QList thread-safe for certain operations?

Scheduled Pinned Locked Moved Solved General and Desktop
6 Posts 4 Posters 672 Views 2 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.
  • deisikD Offline
    deisikD Offline
    deisik
    wrote on last edited by deisik
    #1

    I know that QList is not thread-safe, and you cannot concurrently perform such operations as inserting and deleting from it, which is fairly obvious. But if I think it right, there's no possibility for race condition if you access its different indices at the same time (say, a QList of integers)

    So is QList thread-safe for modifying one of its elements (with replace()) from one thread while reading its other elements (with at()) from another?

    sierdzioS S 2 Replies Last reply
    0
    • deisikD deisik

      @sierdzio said in Is QList thread-safe for certain operations?:

      @deisik but what if you replace() at the same index that your other thread is reading by at()?

      The point is about using locks sparingly and avoiding them when they are unnecessary. So in your case specifically, a lock should kick in. In my case, on the other hand, some indices are never modified once the list has been initialized (filled), so it doesn't make sense to lock the entire list on every read of every index

      Modifying a list invalidates the iterators, so if you are using them in one thread while replacing an element in another thread, it can fail

      Only at() is used for iterating through the list

      Christian EhrlicherC Offline
      Christian EhrlicherC Offline
      Christian Ehrlicher
      Lifetime Qt Champion
      wrote on last edited by
      #4

      As long as you only use const functions from both threads everything is fine.

      Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
      Visit the Qt Academy at https://academy.qt.io/catalog

      deisikD 1 Reply Last reply
      3
      • deisikD deisik

        I know that QList is not thread-safe, and you cannot concurrently perform such operations as inserting and deleting from it, which is fairly obvious. But if I think it right, there's no possibility for race condition if you access its different indices at the same time (say, a QList of integers)

        So is QList thread-safe for modifying one of its elements (with replace()) from one thread while reading its other elements (with at()) from another?

        sierdzioS Offline
        sierdzioS Offline
        sierdzio
        Moderators
        wrote on last edited by
        #2

        @deisik but what if you replace() at the same index that your other thread is reading by at()?

        Modifying a list invalidates the iterators, so if you are using them in one thread while replacing an element in another thread, it can fail.

        (Z(:^

        deisikD 1 Reply Last reply
        1
        • sierdzioS sierdzio

          @deisik but what if you replace() at the same index that your other thread is reading by at()?

          Modifying a list invalidates the iterators, so if you are using them in one thread while replacing an element in another thread, it can fail.

          deisikD Offline
          deisikD Offline
          deisik
          wrote on last edited by deisik
          #3

          @sierdzio said in Is QList thread-safe for certain operations?:

          @deisik but what if you replace() at the same index that your other thread is reading by at()?

          The point is about using locks sparingly and avoiding them when they are unnecessary. So in your case specifically, a lock should kick in. In my case, on the other hand, some indices are never modified once the list has been initialized (filled), so it doesn't make sense to lock the entire list on every read of every index

          Modifying a list invalidates the iterators, so if you are using them in one thread while replacing an element in another thread, it can fail

          Only at() is used for iterating through the list

          Christian EhrlicherC 1 Reply Last reply
          1
          • deisikD deisik

            @sierdzio said in Is QList thread-safe for certain operations?:

            @deisik but what if you replace() at the same index that your other thread is reading by at()?

            The point is about using locks sparingly and avoiding them when they are unnecessary. So in your case specifically, a lock should kick in. In my case, on the other hand, some indices are never modified once the list has been initialized (filled), so it doesn't make sense to lock the entire list on every read of every index

            Modifying a list invalidates the iterators, so if you are using them in one thread while replacing an element in another thread, it can fail

            Only at() is used for iterating through the list

            Christian EhrlicherC Offline
            Christian EhrlicherC Offline
            Christian Ehrlicher
            Lifetime Qt Champion
            wrote on last edited by
            #4

            As long as you only use const functions from both threads everything is fine.

            Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
            Visit the Qt Academy at https://academy.qt.io/catalog

            deisikD 1 Reply Last reply
            3
            • Christian EhrlicherC Christian Ehrlicher

              As long as you only use const functions from both threads everything is fine.

              deisikD Offline
              deisikD Offline
              deisik
              wrote on last edited by
              #5

              @Christian-Ehrlicher said in Is QList thread-safe for certain operations?:

              As long as you only use const functions from both threads everything is fine.

              Okay

              1 Reply Last reply
              0
              • deisikD deisik has marked this topic as solved on
              • deisikD deisik

                I know that QList is not thread-safe, and you cannot concurrently perform such operations as inserting and deleting from it, which is fairly obvious. But if I think it right, there's no possibility for race condition if you access its different indices at the same time (say, a QList of integers)

                So is QList thread-safe for modifying one of its elements (with replace()) from one thread while reading its other elements (with at()) from another?

                S Offline
                S Offline
                SimonSchroeder
                wrote on last edited by
                #6

                @deisik said in Is QList thread-safe for certain operations?:

                So is QList thread-safe for modifying one of its elements (with replace()) from one thread while reading its other elements (with at()) from another?

                This isn't entirely about thread-safety of QList anymore. If you are storing ints inside the QList, at() will retrieve either the old value or the new value (assuming the ints are properly aligned) when do a replace() at the same time on the same index. If you store your own class in the container, your class would have to be somewhat thread-safe as well. However, I don't know an easy mechanism for locking assignment to the object (i.e. replacing its contents) against any access to the object while it is being changed. (Unless you synchronize all access to the object with a mutex.) If you store pointers to objects inside your container you get entirely different problems. Replacing a pointer is as safe as replacing an int. But, you might have a local copy of a pointer to the object which will now be replaced inside the QList. Most likely, the object will then also be destroyed by the thread that replaced the object. The local copy of the pointer is now invalid. Using shared pointers might help in this context, but they will slow down every access to the objects inside your container. (And you need to make sure that you get a copy of the shared pointer. The default implementation of at() will return a reference to whatever is stored inside the container, not a copy.)

                1 Reply Last reply
                1

                • Login

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