summaryrefslogtreecommitdiffstats
path: root/examples/tutorials/addressbook
diff options
context:
space:
mode:
authorOlivier Goffart <ogoffart@trolltech.com>2009-05-18 20:35:42 (GMT)
committerOlivier Goffart <ogoffart@trolltech.com>2009-05-20 14:18:03 (GMT)
commit4a756726ee874ff2ce496e1b113707c65c39a76b (patch)
tree696710e189af90dc6ac19cac2887e779e4257c71 /examples/tutorials/addressbook
parentefb14d56ef9cd327f6358f626f79e3ee88078600 (diff)
downloadQt-4a756726ee874ff2ce496e1b113707c65c39a76b.zip
Qt-4a756726ee874ff2ce496e1b113707c65c39a76b.tar.gz
Qt-4a756726ee874ff2ce496e1b113707c65c39a76b.tar.bz2
Use a per object lock for signal/slots
That way we prevent the current possible race condition that may appears while touching signals slot while object are moved to different threads. For exemple, when we do sender->threadData->mutex->lock(); the sender can possibly be moved to another thread between the moment we get the pointer to the threadData and the moment we aquire the lock. We could check if we locked the right mutex and retry otherwise, but that would break if the threadData (and hence the mutex) get destroyed in between. The per object mutex is implemented with a thread pool. I'm not using the global QThreadPool because we might ends up locking two of their mutex, and that would be dangerous if something else holds a lock on the same mutex (possible deadlock) Putting the mutex pool in a Q_GLOBAL_STATIC doesn't work as it might result of the ppol being deleted before some other object in others Q_GLOBAL_STATIC structures There is no need to lock this mutex in moveToThread as this is safe. When emiting a signal, we do not need to lock the thread data, as the user must ensure that the object is not moved to a thread while emiting a AutoConnection signal. Reviewed-by: Brad
Diffstat (limited to 'examples/tutorials/addressbook')
0 files changed, 0 insertions, 0 deletions