Doc: Generalize problems and solutions of mutex use

These apply to other locks too, not just mutexes.

Move from "Thread Basics" to "Synchronizing Threads"

Change-Id: I6d7051cb225a8c836fb591a28b65d3de8fab4083
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>

1 files changed, 0 insertions, 20 deletions

diff --git a/src/corelib/doc/src/threads-basics.qdoc b/src/corelib/doc/src/threads-basics.qdoc
index 3cf2e66682..8b690c15ae 100644
--- a/src/corelib/doc/src/threads-basics.qdoc
+++ b/src/corelib/doc/src/threads-basics.qdoc
@@ -246,26 +246,6 @@
     }
     \endcode
 
-    What happens if one thread does not unlock a mutex? The result can be a
-    frozen application. In the example above, an exception might be thrown and
-    \c{mutex.unlock()} will never be reached. To prevent problems like this,
-    QMutexLocker should be used.
-
-    \code
-    void Worker::work()
-    {
-        QMutexLocker locker(&mutex);  // Locks the mutex and unlocks when locker exits the scope
-        doWork();
-    }
-    \endcode
-
-    This looks easy, but mutexes introduce a new class of problems: deadlocks.
-    A deadlock happens when a thread waits for a mutex to become unlocked, but
-    the mutex remains locked because the owning thread is waiting for the first
-    thread to unlock it. The result is a frozen application. Mutexes can be
-    used to make a method thread safe. Most Qt methods aren't thread safe
-    because there is always a performance penalty when using mutexes.
-
     \section2 Dealing with Asynchronous Execution
 
     One way to obtain a worker thread's result is by waiting for the thread