Fix construction races in QtNetwork
authorShane Kearns <shane.kearns@accenture.com>
Thu, 6 Oct 2011 14:40:34 +0000 (15:40 +0100)
committerShane Kearns <shane.kearns@accenture.com>
Thu, 6 Oct 2011 16:13:26 +0000 (17:13 +0100)
commit7e662f3727e7c3dd3c41c29ed49bc41d2b66c744
treeb317cd719656cb7d2dca1ea0128b4a4a63ded90a
parent51ed77637a6001f66805e8091ce8616d8f2530db
Fix construction races in QtNetwork

When two threads construct a QNetworkAccessManager at exactly the
same time on an SMP system, there are construction races for some
Q_GLOBAL_STATIC data. This is normal and expected - the losing
thread deletes its instance as part of the Q_GLOBAL_STATIC macro.

However, for two of the classes, destruction of the loser had
side effects. For QNetworkConfigurationMangerPrivate, there was
a crash because of uninitialised variable on the losing side.

For QNetworkAccessBackendFactoryData, a guard mechanism intended
to prevent the data being reconstructed by destructors of other
global static classes was being set by the loser.
To fix this, the bool is changed to a QAtomicInt. In the normal
case, it will have value 0->1 on startup and 1->0 on shutdown.
In the race case, it will have values 0->1->2->1 on startup and
1->0 on shutdown.

Task-Number: QTBUG-20343
Reviewed-By: mread
src/network/access/qnetworkaccessbackend.cpp
src/network/bearer/qnetworkconfigmanager_p.cpp