From 2524cafc8e84862d14fcb57ab68720d04de5659a Mon Sep 17 00:00:00 2001 From: Sze Howe Koh Date: Thu, 3 Oct 2013 22:39:00 +0800 Subject: [PATCH] Doc: Remove convoluted details of uncommon QMutex use case Change-Id: If80068f44fef7ab0692b9dad99aa7e1a30cb72a6 Reviewed-by: Olivier Goffart Reviewed-by: Jerome Pasion --- src/corelib/doc/src/threads-basics.qdoc | 9 --------- 1 file changed, 9 deletions(-) diff --git a/src/corelib/doc/src/threads-basics.qdoc b/src/corelib/doc/src/threads-basics.qdoc index 5d6e0f6ef1..3cf2e66682 100644 --- a/src/corelib/doc/src/threads-basics.qdoc +++ b/src/corelib/doc/src/threads-basics.qdoc @@ -266,15 +266,6 @@ used to make a method thread safe. Most Qt methods aren't thread safe because there is always a performance penalty when using mutexes. - It isn't always possible to lock and unlock a mutex in a method. Sometimes - the need to lock spans several calls. For example, modifying a container - with an iterator requires a sequence of several calls which should not be - interrupted by other threads. In such a scenario, locking can be achieved - with a mutex that is kept outside of the object to be manipulated. With an - external mutex, the duration of locking can be adjusted to the needs of the - operation. One disadvantage is that external mutexes aid locking, but do - not enforce it because users of the object may forget to use it. - \section2 Dealing with Asynchronous Execution One way to obtain a worker thread's result is by waiting for the thread