$(foreach V,$(sort $(.VARIABLES)),\$(if $(filter-out default automatic,\
$(origin $V)),$(warning $V=$($V) ($(value $V)))))
VARS_OLD := $(.VARIABLES)
CUR-DIR := $(shell pwd)
LOG-DIR := $(CUR-DIR)/make-logs
$(foreach v, \
$(filter-out $(VARS_OLD) VARS_OLD,$(.VARIABLES)), \
$(info $(v) = $($(v))))
sudo gedit /etc/dhcp/dhclient.conf
prepend domain-name-servers x.x.x.x, y.y.y.y;
Slow:
while read -r filename; do
rm "$filename"
done <list.txt
For a few arguments):
rm -f $(<list.txt)
xargs -a list.txt -d'\n' rmvolatile keyword.
const, volatile
is a type modifier. It's intended to be used in conjunction with
variables that are accessed and modified in different threads.
Basically, without volatile, either writing multithreaded
programs becomes impossible, or the compiler wastes vast optimization
opportunities. An explanation is in order.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| class Gadget{public: void Wait() { while (!flag_) { Sleep(1000); // sleeps for 1000 milliseconds } } void Wakeup() { flag_ = true; } ...private: bool flag_;}; |
Gadget::Wait above is to check the flag_ member variable every second and return when that variable has been set to true by another thread. At least that's what its programmer intended, but, alas, Wait is incorrect.
Sleep(1000) is a call into an external library that cannot possibly modify the member variable flag_. Then the compiler concludes that it can cache flag_
in a register and use that register instead of accessing the slower
on-board memory. This is an excellent optimization for single-threaded
code, but in this case, it harms correctness: after you call Wait for some Gadget object, although another thread calls Wakeup, Wait will loop forever. This is because the change of flag_ will not be reflected in the register that caches flag_. The optimization is too ... optimistic.
volatile modifier on a variable, the compiler won't
cache that variable in registers — each access will hit the actual
memory location of that variable. So all you have to do to make Gadget's Wait/Wakeup combo work is to qualify flag_ appropriately:
1
2
3
4
5
6
7
| class Gadget{public: ... as above ...private: volatile bool flag_;}; |
volatile stop here and advise you to volatile-qualify the primitive types that you use in multiple threads. However, there is much more you can do with volatile, because it is part of C++'s wonderful type system.
volatile-qualify not only primitive types, but also user-defined types. In that case, volatile modifies the type in a way similar to const. (You can also apply const and volatile to the same type simultaneously.)
const, volatile discriminates
between primitive types and user-defined types. Namely, unlike classes,
primitive types still support all of their operations (addition,
multiplication, assignment, etc.) when volatile-qualified. For example, you can assign a non-volatile int to a volatile int, but you cannot assign a non-volatile object to a volatile object.
volatile works on user-defined types on an example.
1
2
3
4
5
6
7
8
9
10
11
12
13
| class Gadget{public: void Foo() volatile; void Bar(); ...private: String name_; int state_;};...Gadget regularGadget;volatile Gadget volatileGadget; |
volatile is not that useful with objects, prepare for some surprise.
1
2
3
4
5
6
7
8
| volatileGadget.Foo(); // ok, volatile fun called for // volatile objectregularGadget.Foo(); // ok, volatile fun called for // non-volatile objectvolatileGadget.Bar(); // error! Non-volatile function called for // volatile object! |
volatile counterpart is trivial. However, just as with const, you cannot make the trip back from volatile to non-qualified. You must use a cast:
1
2
| Gadget& ref = const_castref.Bar(); // ok |
volatile-qualified class gives access only to a
subset of its interface, a subset that is under the control of the class
implementer. Users can gain full access to that type's interface only
by using a const_cast. In addition, just like constness, volatileness propagates from the class to its members (for example, volatileGadget.name_ and volatileGadget.state_ are volatile variables).
Acquire and Release primitives. Once you call Acquire in some thread, any other thread calling Acquire will block. Later, when that thread calls Release, precisely one thread blocked in an Acquire call will be released. In other words, for a given mutex, only one thread can get processor time in between a call to Acquire and a call to Release. The executing code between a call to Acquire and a call to Release is called a critical section.
(Windows terminology is a bit confusing because it calls the mutex
itself a critical section, while "mutex" is actually an inter-process
mutex. It would have been nice if they were called thread mutex and
process mutex.)
volatile connection. We do this by drawing a parallel between the C++ types' world and the threading semantics world.
Outside a critical section, any thread might interrupt
any other at any time; there is no control, so consequently variables
accessible from multiple threads are volatile. This is in keeping with the original intent of volatile — that of preventing the compiler from unwittingly caching values used by multiple threads at once.Inside a critical section defined by a mutex, only one thread has access. Consequently, inside a critical section, the executing code has single-threaded semantics. The controlled variable is not volatile anymore — you can remove the volatile qualifier.volatile outside a critical section, and non-volatile inside a critical section.
volatile qualifier from a type by applying a const_cast. If we manage to put these two operations together, we create a connection between C++'s type system and an application's threading semantics. We can make the compiler check race conditions for us.
const_cast. Let's develop a
LockingPtr class template that you initialize with a volatile object obj and a mutex mtx. During its lifetime, a LockingPtr keeps mtx acquired. Also, LockingPtr offers access to the volatile-stripped obj. The access is offered in a smart pointer fashion, through operator-> and operator*. The const_cast is performed inside LockingPtr. The cast is semantically valid because LockingPtr keeps the mutex acquired for its lifetime.
Mutex with which LockingPtr will work:
1
2
3
4
5
6
7
| class Mutex{public: void Acquire(); void Release(); ... }; |
LockingPtr, you implement Mutex using your operating system's native data structures and primitive functions.
LockingPtr is templated with the type of the controlled variable. For example, if you want to control a Widget, you use a LockingPtr volatile Widget.
LockingPtr's definition is very simple. LockingPtr implements an unsophisticated smart pointer. It focuses solely on collecting a const_cast and a critical section.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| template <typename T>class LockingPtr {public: // Constructors/destructors LockingPtr(volatile T& obj, Mutex& mtx) : pObj_(const_cast pMtx_(&mtx) { mtx.Lock(); } ~LockingPtr() { pMtx_->Unlock(); } // Pointer behavior T& operator*() { return *pObj_; } T* operator->() { return pObj_; }private: T* pObj_; Mutex* pMtx_; LockingPtr(const LockingPtr&); LockingPtr& operator=(const LockingPtr&);}; |
LockingPtr is a very useful aid in writing correct multithreaded code. You should define objects that are shared between threads as volatile and never use const_cast with them — always use LockingPtr automatic objects. Let's illustrate this with an example.
vector object:
1
2
3
4
5
6
7
8
9
| class SyncBuf {public: void Thread1(); void Thread2();private: typedef vector<char> BufT; volatile BufT buffer_; Mutex mtx_; // controls access to buffer_}; |
LockingPtr to get controlled access to the buffer_ member variable:
1
2
3
4
5
6
7
| void SyncBuf::Thread1() { LockingPtr BufT::iterator i = lpBuf->begin(); for (; i != lpBuf->end(); ++i) { ... use *i ... }} |
buffer_, you must create a LockingPtr pointing to it. Once you do that, you have access to vector's entire interface.
1
2
3
4
5
6
7
8
| void SyncBuf::Thread2() { // Error! Cannot access 'begin' for a volatile object BufT::iterator i = buffer_.begin(); // Error! Cannot access 'end' for a volatile object for (; i != lpBuf->end(); ++i) { ... use *i ... }} |
buffer_ until you either apply a const_cast or use LockingPtr. The difference is that LockingPtr offers an ordered way of applying const_cast to volatile variables.
LockingPtr is remarkably expressive. If you only need to call one function, you can create an unnamed temporary LockingPtr object and use it directly:
1
2
3
| unsigned int SyncBuf::Size() { return LockingPtr} |
volatile protects objects against uncontrolled access and how LockingPtr
provides a simple and effective way of writing thread-safe code. Let's
now return to primitive types, which are treated differently by volatile.
int.
1
2
3
4
5
6
7
8
9
| class Counter{public: ... void Increment() { ++ctr_; } void Decrement() { —ctr_; }private: int ctr_;}; |
Increment and Decrement are to be called from different threads, the fragment above is buggy. First, ctr_ must be volatile. Second, even a seemingly atomic operation such as ++ctr_ is actually a three-stage operation. Memory itself has no arithmetic capabilities. When incrementing a variable, the processor:
LockingPtr:
1
2
3
4
5
6
7
8
9
10
| class Counter{public: ... void Increment() { ++*LockingPtr<int>(ctr_, mtx_); } void Decrement() { —*LockingPtr<int>(ctr_, mtx_); }private: volatile int ctr_; Mutex mtx_;}; |
SyncBuf's code. Why? Because with Counter, the compiler will not warn you if you mistakenly access ctr_ directly (without locking it). The compiler compiles ++ctr_ if ctr_ is volatile,
although the generated code is simply incorrect. The compiler is not
your ally anymore, and only your attention can help you avoid race
conditions.
volatile with those structures. Paradoxically, it's worse to use volatile directly with built-ins, in spite of the fact that initially this was the usage intent of volatile!
volatile
data members; now let's think of designing classes that in turn will be
part of larger objects and shared between threads. Here is where volatile member functions can be of great help.
volatile-qualify only those member functions that are thread safe. You must assume that code from the outside will call the volatile functions from any code at any time. Don't forget: volatile equals free multithreaded code and no critical section; non-volatile equals single-threaded scenario or inside a critical section.
Widget that implements an operation in two variants — a thread-safe one and a fast, unprotected one.
1
2
3
4
5
6
7
8
9
| class Widget{public: void Operation() volatile; void Operation(); ...private: Mutex mtx_;}; |
Widget's user can invoke Operation using a uniform syntax either for volatile objects and get thread safety, or for regular objects and get speed. The user must be careful about defining the shared Widget objects as volatile.
volatile member function, the first operation is usually to lock this with a LockingPtr. Then the work is done by using the non- volatile sibling:
1
2
3
4
5
| void Widget::Operation() volatile{ LockingPtrthis, mtx_); lpThis->Operation(); // invokes the non-volatile function} |
volatile to your advantage. You must stick to the following rules:
volatile.volatile directly with primitive types.volatile member functions to express thread safety.LockingPtr,
you can write thread-safe code and worry much less about race
conditions, because the compiler will worry for you and will diligently
point out the spots where you are wrong.
volatile and LockingPtr
to great effect. The code is clean and understandable. I recall a
couple of deadlocks, but I prefer deadlocks to race conditions because
they are so much easier to debug. There were virtually no problems
related to race conditions. But then you never know.