[Qt-interest] thread safety of Qt containers
Thiago Macieira
thiago at kde.org
Mon Apr 26 13:39:43 CEST 2010
Em Segunda-feira 26 Abril 2010, às 12:14:56, Andre Somers escreveu:
> > There's a mutex. That ensures that there's only one thread accessing the
> > container at a time.
> >
> >
>
> So, performing a very simple operation using QtConcurrent is not that
> efficient, because of the locking and unlocking of the mutex? I seem to
> recall that mutexes are relatively expensive resources to aquire, right?
No, that's not correct.
QMutex is very fast on all platforms.
But yeah, there's a serialisation point. Future improvements to QtConcurrent
could work by partitioning the data and distributing to the threads ahead of
time, so that they can work without locks, until they run out of data.
> >> I am looking into QtConcurrent to speed up some heavy calculation work
> >> that I need to do. However, the amount of data is such that copying
> >> around data is really not an option. It is simply too much (datasets may
> >> range into the GB range).
> >>
> >>
>
> Would it be save to read from the same datastructure from multiple
> threads, if not write to them?
Yes, concurrent read-only access to Qt tool classes (all of them) is thread-
safe. If you find any issues (like lazy parsing of QUrl, which is a known
issue), it will be treated as a bug and fixed.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Development Frameworks
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100426/4cafae1c/attachment.bin
More information about the Qt-interest-old
mailing list