[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