From 0be453e60c0249b29e7e8781b58b27ab5910ea17 Mon Sep 17 00:00:00 2001 From: Wolfgang Bangerth Date: Mon, 22 Sep 2014 10:21:03 -0500 Subject: [PATCH] Convert two more places where we use .... --- include/deal.II/base/thread_management.h | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/include/deal.II/base/thread_management.h b/include/deal.II/base/thread_management.h index ef5eb45c38..821a59ee28 100644 --- a/include/deal.II/base/thread_management.h +++ b/include/deal.II/base/thread_management.h @@ -93,8 +93,8 @@ namespace Threads * is thrown between the locking and unlocking point, the * destructor makes sure that the mutex is unlocked; this would * not automatically be the case when you lock and unlock the - * mutex "by hand", i.e. using acquire() and - * release(). + * mutex "by hand", i.e. using Mutex::acquire() and + * Mutex::release(). */ class ScopedLock { @@ -132,10 +132,10 @@ namespace Threads * implementing real condition variable semantics. It allows to * write programs such that they start new threads and/or lock * objects in multithreading mode, and use dummy thread management - * and synchronisation classes instead when running in single-thread + * and synchronization classes instead when running in single-thread * mode. Specifically, the new_thread() functions only call the * function but wait for it to return instead of running in on - * another thread, and the mutices do nothing really. The only + * another thread, and the mutexes do nothing really. The only * reason to provide such a function is that the program can be * compiled both in MT and non-MT mode without difference. * @@ -269,8 +269,8 @@ namespace Threads * is thrown between the locking and unlocking point, the * destructor makes sure that the mutex is unlocked; this would * not automatically be the case when you lock and unlock the - * mutex "by hand", i.e. using acquire() and - * release(). + * mutex "by hand", i.e. using Mutex::acquire() and + * Mutex::release(). */ class ScopedLock { -- 2.39.5