Is insert function of QSet thread-safe?
-
wrote on 27 Aug 2018, 05:47 last edited by
Segmentation fault occured inner QHash function.
Because CountDataPixel class inherits QThread, I conjectured that something bad happens If I use QSet insert with multiple threads.
This is what I think : Even though QPair(x1, y1), QPair(x2, y2) are different, they are calculated in the same hash value. If two threads insert each QPair simultaneously, confliction occurs.Am I correct? If not, why does segmentation fault occur in the inner hash function?
-
Segmentation fault occured inner QHash function.
Because CountDataPixel class inherits QThread, I conjectured that something bad happens If I use QSet insert with multiple threads.
This is what I think : Even though QPair(x1, y1), QPair(x2, y2) are different, they are calculated in the same hash value. If two threads insert each QPair simultaneously, confliction occurs.Am I correct? If not, why does segmentation fault occur in the inner hash function?
@Aaron-Kim said in Is insert function of QSet thread-safe?:
Is insert function of QSet thread-safe?
No, it is not thread-safe.
I conjectured that something bad happens If I use QSet insert with multiple threads.
That is correct.
This is what I think : Even though QPair(x1, y1), QPair(x2, y2) are different, they are calculated in the same hash value. If two threads insert each QPair simultaneously, confliction occurs.
Am I correct?
No. It doesn't matter if the 2 pairs have the same hash value or different hash values.
If you try to modify the same object from 2 different threads at the same time, they can overwrite parts of each other and corrupt your data. Because QSet is not thread-safe, you must lock it and make sure that only 1 thread can read/write it at any given time.
-
@Aaron-Kim said in Is insert function of QSet thread-safe?:
Is insert function of QSet thread-safe?
No, it is not thread-safe.
I conjectured that something bad happens If I use QSet insert with multiple threads.
That is correct.
This is what I think : Even though QPair(x1, y1), QPair(x2, y2) are different, they are calculated in the same hash value. If two threads insert each QPair simultaneously, confliction occurs.
Am I correct?
No. It doesn't matter if the 2 pairs have the same hash value or different hash values.
If you try to modify the same object from 2 different threads at the same time, they can overwrite parts of each other and corrupt your data. Because QSet is not thread-safe, you must lock it and make sure that only 1 thread can read/write it at any given time.
-
@JKSH Thanks for reply ! I just change it QSet to QQueue and move all the elements from QSet to QQueue after multithreaded task. (Even though it is a little bit slower)
wrote on 27 Aug 2018, 09:59 last edited by@Aaron-Kim said in Is insert function of QSet thread-safe?:
@JKSH Thanks for reply ! I just change it QSet to QQueue and move all the elements from QSet to QQueue after multithreaded task. (Even though it is a little bit slower)
Interesting. Because QQueue isn't thread-safe, either. Unless you added a lock, or use separate queues for each thread, you have just hidden the problem, and it may pop up again at any time.
-
@Aaron-Kim said in Is insert function of QSet thread-safe?:
@JKSH Thanks for reply ! I just change it QSet to QQueue and move all the elements from QSet to QQueue after multithreaded task. (Even though it is a little bit slower)
Interesting. Because QQueue isn't thread-safe, either. Unless you added a lock, or use separate queues for each thread, you have just hidden the problem, and it may pop up again at any time.
wrote on 27 Aug 2018, 12:11 last edited by@Asperamanca Isn't it thread safe if I insert only different elements, without any other operations? (Order of elements is not a problem)
-
@Asperamanca Isn't it thread safe if I insert only different elements, without any other operations? (Order of elements is not a problem)
Isn't it thread safe if I insert only different elements, without any other operations?
You are assuming internal details about "black box" containers. Don't do that.
The documentation does not write that QSet or QQueue are thread-safe, so they aren't.
Even if it works for you, it may not work on another platform or another Qt version.
Regards
-
Isn't it thread safe if I insert only different elements, without any other operations?
You are assuming internal details about "black box" containers. Don't do that.
The documentation does not write that QSet or QQueue are thread-safe, so they aren't.
Even if it works for you, it may not work on another platform or another Qt version.
Regards
-
@Aaron-Kim they said writing on different objects is safe, they did not talk about elements of the same object.
of course that should apply for almost every container, includin Qt's.
Regards
-
@Asperamanca Isn't it thread safe if I insert only different elements, without any other operations? (Order of elements is not a problem)
First, let's be clear about terminology. The important names are:
- Container: An object that can hold multiple other objects (or primitives)
- Element: An object (or primitive) that is stored inside a container
@Aaron-Kim said in Is insert function of QSet thread-safe?:
someone said that STL is thread-safe for writing different objects in this post.
The accepted answer in that post talks about modifying existing elements inside a container.
Inserting does not fit this criteria because
insert()does not modify an existing element. Instead, it modifies the container itself! Therefore, inserting into an STL container is definitely not thread-safe.@aha_1980 said in Is insert function of QSet thread-safe?:
@Aaron-Kim they said writing on different objects is safe, they did not talk about elements of the same object.
The C++ standard does say "implementations are required to avoid data races when the contents of the contained object in different elements in the same sequence, excepting
vector<bool>, are modified concurrently." -
wrote on 28 Aug 2018, 04:54 last edited by
Thanks for reply! I got it.
8/10