diff options
author | David Faure <david.faure@kdab.com> | 2013-08-19 10:45:06 +0200 |
---|---|---|
committer | The Qt Project <gerrit-noreply@qt-project.org> | 2013-08-21 23:50:59 +0200 |
commit | 85b24bb2dea97c3a9b013bacd5a422b26fe5d14b (patch) | |
tree | 338c30d92dbfe4c80438367ba44c96f29f880b01 /doc/global/externalsites | |
parent | 1de1470189991f5334439048a4d875e97193a82d (diff) |
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%).
Change-Id: I993444eef8bc68eff9badd581fae3626dfd1cc6d
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Diffstat (limited to 'doc/global/externalsites')
0 files changed, 0 insertions, 0 deletions