summaryrefslogtreecommitdiffstats
path: root/translations/linguist_zh_TW.ts
diff options
context:
space:
mode:
authorDavid Faure <david.faure@kdab.com>2013-08-19 08:45:06 (GMT)
committerThe Qt Project <gerrit-noreply@qt-project.org>2013-11-15 11:42:27 (GMT)
commit521ea9cc0e4014ce5186c727ba30026d7b7edc60 (patch)
treef717d7f9419009aabe692f29622d0d5530818b4a /translations/linguist_zh_TW.ts
parent735f4851843892a9562dbd59b319d436dc04055b (diff)
downloadQt-521ea9cc0e4014ce5186c727ba30026d7b7edc60.zip
Qt-521ea9cc0e4014ce5186c727ba30026d7b7edc60.tar.gz
Qt-521ea9cc0e4014ce5186c727ba30026d7b7edc60.tar.bz2
QThreadPool: fix data races in activeThreadCount()
Rather than trying to make it lock-free (which requires double-bookkeeping of 4 atomic ints!), just lock the mutex before calling it. tst_bench_qthreadpool shows no difference whatsoever between the two solutions, I get 0.005 msecs per iteration in startRunnables(). Of course looping over calls to activeThreadCount() is a bit slower, from 0.0002 msecs per iteration to 0.00027 msecs, i.e. 35% more. But polling activeThreadCount() from the app is a really wrong thing to do anyway, this benchmark was just for my own curiosity about the price of a mutex in a function that sums up 4 ints. What matters is start() performance, which is unchanged (0.00007 msecs is just noise compared to a 0.005 total, that's 1.4%). Backport from qtbase/85b24bb2dea97c3a9b013bacd5a422b26fe5d14b Change-Id: Id32791069bc1e2dd61cef708d5287c9f9b7e5582 Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Diffstat (limited to 'translations/linguist_zh_TW.ts')
0 files changed, 0 insertions, 0 deletions