Author: gonwan

std::thread and std::future in C++11

December 12, 2014 by gonwan·0 Comments

This is a quick note to chapter 4 of C++ Concurrency in Action.

1. std::thread

In C++11, It’s quite simple to create a separate thread using std::thread. Following code will simply output “hello world” or “world hello”:

#include <iostream>
#include <thread>
using namespace std;

void foo(const char *s) {
    cout << s << endl;
}

int main() {
    thread t(foo, "hello");
    cout << "world" << endl;
    /* destructor of std::thread calls std::terminate(), so we should call join() manually. */
    t.join();
    return 0;
}

#include <iostream>

#include <thread>

using namespace std;

void foo(const char *s) {

cout << s << endl;

}

int main() {

thread t(foo, "hello");

cout << "world" << endl;

/* destructor of std::thread calls std::terminate(), so we should call join() manually. */

t.join();

return 0;

}

2. std::mutex and std::condition_variable

If you need synchronization between threads, there are std::mutex and std::condition_variable. The semantics are the same with that in pthread library. Here’s a simple producer/consumer demo:

#include <iostream>
#include <chrono>
#include <condition_variable>
#include <mutex>
#include <queue>
#include <thread>
using namespace std;

queue<int> q;
mutex m;
condition_variable c;
const chrono::milliseconds ms(1000);

void producer() {
    static int i = 0;
    while (true) {
        m.lock();
        cout << "pushing " << i << endl;
        q.push(i++);
        c.notify_one();
        m.unlock();
        this_thread::sleep_for(ms);
    }
}

void consumer() {
    while (true) {
        unique_lock<mutex> lk(m);
        c.wait(lk, [](){ return !q.empty(); });
        int i = q.front();
        cout << "popping " << i << endl;
        q.pop();
        lk.unlock();
        this_thread::sleep_for(ms);
    }
}

int main() {
    thread t(consumer);
    thread t2(producer);
    t.join();
    t2.join();
    return 0;
}

#include <iostream>

#include <chrono>

#include <condition_variable>

#include <mutex>

#include <queue>

#include <thread>

using namespace std;

queue<int> q;

mutex m;

condition_variable c;

const chrono::milliseconds ms(1000);

void producer() {

static int i = 0;

while (true) {

m.lock();

cout << "pushing " << i << endl;

q.push(i++);

c.notify_one();

m.unlock();

this_thread::sleep_for(ms);

}

void consumer() {

while (true) {

unique_lock<mutex> lk(m);

c.wait(lk, [](){ return !q.empty(); });

int i = q.front();

cout << "popping " << i << endl;

q.pop();

lk.unlock();

this_thread::sleep_for(ms);

}

int main() {

thread t(consumer);

thread t2(producer);

t.join();

t2.join();

return 0;

}

3. std::future with std::async()

C++11 also simplifies our work with one-off events with std::future. std::future provides a mechanism to access the result of asynchronous operations. It can be used with std::async(), std::packaged_task and std::promise. Starting with std::async():

#include <iostream>
#include <future>
using namespace std;

void foo(const char *s) {
    cout << s << endl;
}

int bar(int a, int b) {
    return a + b;
}

int main() {
    /* auto will be simpler */
    future<void> f = std::async(foo, "hello");
    future<int> f2 = std::async(launch::async, bar, 1, 2);
    /* f.get() is required if f is deferred by the library */
    //f.get();
    /* std::async() can return a value */
    cout << "1 + 2 = " << f2.get() << endl;
    /* threads created by std::async() are joined automatically */
    return 0;
}

#include <iostream>

#include <future>

using namespace std;

void foo(const char *s) {

cout << s << endl;

}

int bar(int a, int b) {

return a + b;

}

int main() {

/* auto will be simpler */

future<void> f = std::async(foo, "hello");

future<int> f2 = std::async(launch::async, bar, 1, 2);

/* f.get() is required if f is deferred by the library */

//f.get();

/* std::async() can return a value */

cout << "1 + 2 = " << f2.get() << endl;

/* threads created by std::async() are joined automatically */

return 0;

}

std::async() gives two advantages over the direct usage of std::thread. Threads created by it are automatically joined. And we can now have a return value. std::async() decides whether to run the callback function in a separate thread or just in the current thread. But there’s a chance to specify a control flag(launch::async or launch::deferred) to tell the library, what approach we want it to run the callback.

When testing With gcc-4.8, foo() is not called. But with VC++2013, it does output “hello”.

4. std::future with std::packaged_task

With std::async(), we cannot control when our callback function is invoked. That’s what std::packaged_task is designed to deal with. It’s just a wrapper to callables. We can request an associated std::future from it. And when a std::packaged_task is invoked and finished, the associated future will be ready:

#include <iostream>
#include <future>
using namespace std;

void foo() {
    cout << "in pt.." << endl;
}

int bar(int a, int b) {
    cout << "in pt2.." << endl;
    return a + b;
}

/* associate with tasks */
packaged_task<void()> pt(foo);
packaged_task<int(int,int)> pt2(bar);

void waiter() {
    /* get associated future */
    auto f = pt.get_future();
    /* wait here */
    f.get();
    cout << "after f.get().." << endl;
}

void waiter2() {
    auto f2 = pt2.get_future();
    f2.get();
    cout << "after f2.get().." << endl;
}

int main() {
    auto t = std::async(launch::async, waiter);
    auto t2 = std::async(launch::async, waiter2);
    /* associated futures will be ready when the packaged tasks complete */
    pt();
    pt2(1, 2);
    return 0;
}

#include <iostream>

#include <future>

using namespace std;

void foo() {

cout << "in pt.." << endl;

}

int bar(int a, int b) {

cout << "in pt2.." << endl;

return a + b;

}

/* associate with tasks */

packaged_task<void()> pt(foo);

packaged_task<int(int,int)> pt2(bar);

void waiter() {

/* get associated future */

auto f = pt.get_future();

/* wait here */

f.get();

cout << "after f.get().." << endl;

}

void waiter2() {

auto f2 = pt2.get_future();

f2.get();

cout << "after f2.get().." << endl;

}

int main() {

auto t = std::async(launch::async, waiter);

auto t2 = std::async(launch::async, waiter2);

/* associated futures will be ready when the packaged tasks complete */

pt();

pt2(1, 2);

return 0;

}

In waiter() and waiter2(), future::get() blocks until the associating std::packaged_task completes. You will always get “in pt” before “after f.get()” and “in pt2” before “after f2.get()”. They are synchronized.

5. std::future with std::promise

You may also need to get notified in the middle of a task. std::promise can help you. It works like a lightweight event.

Future and Promise are the two separate sides of an asynchronous operation. std::promise is used by the “producer/writer”, while std::future is used by the “consumer/reader”. The reason it is separated into these two interfaces is to hide the “write/set” functionality from the “consumer/reader”:

#include <iostream>
#include <future>
using namespace std;

promise<bool> p;
promise<int> p2;

void waiter() {
    /* get associated future */
    auto f = p.get_future();
    /* wait here */
    f.get();
    cout << "after f.get().." << endl;
}

void waiter2() {
    auto f2 = p2.get_future();
    try {
        f2.get();
    } catch (...) {
        /* caught exception */
        cout << "caught exception in f2.get().." << endl;
    }
    cout << "after f2.get().." << endl;
}

int main() {
    auto t = std::async(launch::async, waiter);
    auto t2 = std::async(launch::async, waiter2);
    /* associated futures will be ready after a value is set */
    cout << "setting p.." << endl;
    p.set_value(true);
    /* exceptions can also be set */
    cout << "setting p2.." << endl;
    p2.set_exception(std::exception_ptr(nullptr));
    return 0;
}

#include <iostream>

#include <future>

using namespace std;

promise<bool> p;

promise<int> p2;

void waiter() {

/* get associated future */

auto f = p.get_future();

/* wait here */

f.get();

cout << "after f.get().." << endl;

}

void waiter2() {

auto f2 = p2.get_future();

try {

f2.get();

} catch (...) {

/* caught exception */

cout << "caught exception in f2.get().." << endl;

}

cout << "after f2.get().." << endl;

}

int main() {

auto t = std::async(launch::async, waiter);

auto t2 = std::async(launch::async, waiter2);

/* associated futures will be ready after a value is set */

cout << "setting p.." << endl;

p.set_value(true);

/* exceptions can also be set */

cout << "setting p2.." << endl;

p2.set_exception(std::exception_ptr(nullptr));

return 0;

}

Again in waiter() and waiter2(), future::get() blocks until a value or an exception is set into the associating std::promise. So “setting p” is always before “f.get()” and “setting p2” is always before “f2.get()”. They are synchronized.

NOTE: std::future seems to be not correctly implemented in VC++2013. So the last two code snippet do not work with it. But you can try the online VC++2015 compiler(still in preview as this writing), it works.

Two-phase Lookup in C++ Templates

December 12, 2014 by gonwan·0 Comments

This is a quick note to C++ Templates: The Complete Guide. Name Taxonomy comes first in chapter 9:

Qualified name: This term is not defined in the standard, but we use it to refer to names that undergo so-called qualified lookup. Specifically, this is a qualified-id or an unqualified-id that is used after an explicit member access operator (. or ->). Examples are S::x, this->f, and p->A::m. However, just class_mem in a context that is implicitly equivalent to this->class_mem is not a qualified name: The member access must be explicit.

Unqualified name: An unqualified-id that is not a qualified name. This is not a standard term but corresponds to names that undergo what the standard calls unqualified lookup.

Dependent name: A name that depends in some way on a template parameter. Certainly any qualified or unqualified name that explicitly contains a template parameter is dependent. Furthermore, a qualified name that is qualified by a member access operator (. or ->) is dependent if the type of the expression on the left of the access operator depends on a template parameter. In particular, b in this->b is a dependent name when it appears in a template. Finally, the identifier ident in a call of the form ident(x, y, z) is a dependent name if and only if any of the argument expressions has a type that depends on a template parameter.

Nondependent name: A name that is not a dependent name by the above description.

And the definition from Chapter 10:

This leads to the concept of two-phase lookup: The first phase is the parsing of a template, and the second phase is its instantiation.

During the first phase, nondependent names are looked up while the template is being parsed using both the ordinary lookup rules and, if applicable, the rules for argument-dependent lookup (ADL). Unqualified dependent names (which are dependent because they look like the name of a function in a function call with dependent arguments) are also looked up that way, but the result of the lookup is not considered complete until an additional lookup is performed when the template is instantiated.

During the second phase, which occurs when templates are instantiated at a point called the point of instantiation(POI), dependent qualified names are looked up (with the template parameters replaced with the template arguments for that specific instantiation), and an additional ADL is performed for the unqualified dependent names.

To summarize: nondependent names are looked up in first phase, qualified dependent names are looked up in second phase, and unqualified dependent names are looked up in both phases. Some code to illustrate how this works:

#include <iostream>

template <typename T>
struct Base {
    typedef int I;
};

template <typename T>
struct Derived : Base<T> {
    void foo() {
        //typename Base<T>::I i = 1.024;
        I i = 1.024;
        std::cout << i << std::endl;
    }
};

template <>
struct Base<void> {
    //const static int I = 0;
    typedef double I;
};

int main() {
    Derived<bool> d1;
    d1.foo();
    Derived<void> d2;
    d2.foo();
    return 0;
}

#include <iostream>

template <typename T>

struct Base {

typedef int I;

};

template <typename T>

struct Derived : Base<T> {

void foo() {

//typename Base<T>::I i = 1.024;

I i = 1.024;

std::cout << i << std::endl;

}

};

template <>

struct Base<void> {

//const static int I = 0;

typedef double I;

};

int main() {

Derived<bool> d1;

d1.foo();

Derived<void> d2;

d2.foo();

return 0;

}

Now look into Derived::foo(). I is a nondependent name, it should be looked up only in first phase. But at that point, the compiler cannot decide the type of it. When instantiated with Derived<bool>, I is type int. When instantiated with Derived<void>, I is type double. So it’s better to look up I in the second phase. We can use typename Base<T>::I i = 1.024; to delay the look up, for I is a qualified dependent name now.

Unfortunately, two-phase lookup(C++03 standard) is not fully supported in VC++ even in VC++2013. It compiles well and gives your most expecting result(output 1 and 1.024). With gcc-4.6, it gives errors like:

temp1.cpp: In member function ‘void Derived<T>::foo()’:
temp1.cpp:12:9: error: ‘I’ was not declared in this scope
temp1.cpp:12:11: error: expected ‘;’ before ‘i’
temp1.cpp:13:22: error: ‘i’ was not declared in this scope

temp1.cpp: In member function ‘void Derived<T>::foo()’:

temp1.cpp:12:9: error: ‘I’ was not declared in this scope

temp1.cpp:12:11: error: expected ‘;’ before ‘i’

temp1.cpp:13:22: error: ‘i’ was not declared in this scope

Another code snippet:

#ifdef _USE_STRUCT
/* ADL of nondependent names in two-phase lookup should
 * only works for types that have an associated namespace. */
struct Int { 
    Int(int) { };
};
#else
typedef int Int;
#endif

template <typename T>
void f(T i) {
    g(i);
};

void g(Int i) {
}

int main() {
    f(Int(1024));
    return 0;
}

#ifdef _USE_STRUCT

/* ADL of nondependent names in two-phase lookup should

* only works for types that have an associated namespace. */

struct Int {

Int(int) { };

};

#else

typedef int Int;

#endif

template <typename T>

void f(T i) {

g(i);

};

void g(Int i) {

}

int main() {

f(Int(1024));

return 0;

}

When the compiler sees f(), g() has not been declared. This code should not compile, if f() is a nontemplate function. Since f() is a template function and g() is a nondependent name, the compiler can use ADL in first phase to find the declaration of g(). Note, a user-defined type like Int is required here. Since int is a primitive type, it has no associated namespace, and no ADL is performed.

VC++2013 still compiles well with this code. You can find some clue that they will not support it in the next VC++2015 release. With gcc, they declared to fully support two-phase lookup in gcc-4.7. I used gcc-4.8, error output looks like:

temp2.cpp: In instantiation of ‘void f(T) [with T = int]’:
temp2.cpp:20:16:   required from here
temp2.cpp:13:8: error: ‘g’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
     g(i);
        ^
temp2.cpp:16:6: note: ‘void g(Int)’ declared here, later in the translation unit
 void g(Int i) {
      ^

temp2.cpp: In instantiation of ‘void f(T) [with T = int]’:

temp2.cpp:20:16: required from here

temp2.cpp:13:8: error: ‘g’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]

g(i);

temp2.cpp:16:6: note: ‘void g(Int)’ declared here, later in the translation unit

void g(Int i) {

And the code compiles well with self-defined type Int(using -D_USE_STRUCT switch).

Switching to the Linuxmint 17.1 Theme

December 2, 2014 by gonwan·0 Comments

Just upgraded to Linuxmint 17.1. Themes in the distribution were greatly improved. They’ve done a better job than Ubuntu, so I switched to the mint theme.

No broken visual glitch any more in eclipse. And it seems the new themes include fixes for the black background color for tooltips issue. See eclipse FAQ here.

You can compare with the previous screenshot: Configuring Ubuntu Themes in Linuxmint 17. The only fix I want to apply is to make the theme look brighter. First, go to /usr/share/themes/Mint-X-Aqua. For gtk3 applications, patch with:

--- gtk-3.0/gtk-main.css.bak	2014-12-02 14:06:03.864745990 +0800
+++ gtk-3.0/gtk-main.css	2014-12-02 14:21:32.508879444 +0800
@@ -1,8 +1,8 @@
 /* Default Color Scheme */
 
-@define-color theme_bg_color #d6d6d6;
+@define-color theme_bg_color #e3e3e3;
 @define-color theme_fg_color #212121;
-@define-color theme_base_color #f7f7f7;
+@define-color theme_base_color #fafafa;
 @define-color theme_text_color #212121;
 @define-color theme_selected_bg_color #6cabcd;
 @define-color theme_selected_fg_color #f5f5f5;

--- gtk-3.0/gtk-main.css.bak 2014-12-02 14:06:03.864745990 +0800

+++ gtk-3.0/gtk-main.css 2014-12-02 14:21:32.508879444 +0800

@@ -1,8 +1,8 @@

/* Default Color Scheme */

-@define-color theme_bg_color #d6d6d6;

+@define-color theme_bg_color #e3e3e3;

@define-color theme_fg_color #212121;

-@define-color theme_base_color #f7f7f7;

+@define-color theme_base_color #fafafa;

@define-color theme_text_color #212121;

@define-color theme_selected_bg_color #6cabcd;

@define-color theme_selected_fg_color #f5f5f5;

For gtk2 applications, patch with:

--- gtk-2.0/gtkrc.bak	2014-12-02 14:22:07.798517093 +0800
+++ gtk-2.0/gtkrc	2014-12-02 14:22:26.575901978 +0800
@@ -1,6 +1,6 @@
 # These are the defined colors for the theme, you can change them in GNOME's appearance preferences.
 
-gtk_color_scheme = "bg_color:#d6d6d6\nselected_bg_color:#6cabcd\nbase_color:#F7F7F7" # Background, base.
+gtk_color_scheme = "bg_color:#e3e3e3\nselected_bg_color:#6cabcd\nbase_color:#fafafa" # Background, base.
 gtk_color_scheme = "fg_color:#212121\nselected_fg_color:#f5f5f5\ntext_color:#212121" # Foreground, text.
 gtk_color_scheme = "tooltip_bg_color:#fbeaa0\ntooltip_fg_color:#212121" # Tooltips.
 gtk_color_scheme = "link_color:#08c" # Hyperlinks

--- gtk-2.0/gtkrc.bak 2014-12-02 14:22:07.798517093 +0800

+++ gtk-2.0/gtkrc 2014-12-02 14:22:26.575901978 +0800

@@ -1,6 +1,6 @@

# These are the defined colors for the theme, you can change them in GNOME's appearance preferences.

-gtk_color_scheme = "bg_color:#d6d6d6\nselected_bg_color:#6cabcd\nbase_color:#F7F7F7" # Background, base.

+gtk_color_scheme = "bg_color:#e3e3e3\nselected_bg_color:#6cabcd\nbase_color:#fafafa" # Background, base.

gtk_color_scheme = "fg_color:#212121\nselected_fg_color:#f5f5f5\ntext_color:#212121" # Foreground, text.

gtk_color_scheme = "tooltip_bg_color:#fbeaa0\ntooltip_fg_color:#212121" # Tooltips.

gtk_color_scheme = "link_color:#08c" # Hyperlinks

Different Semantics Between Win32 Events and Condition Variables

November 26, 2014 by gonwan·0 Comments

Following the last post, I’m trying to implement a thread pool for practise, which supposed to work under both Windows and Linux platform. But the different semantics between Win32 events and condition variables makes it impossible to code in a unified logic. First, Linux uses mutex and condition variable to keep synchronization. While there is only event under Windows. Then, pthread_cond_signal() does nothing if no thread is currently waiting on the condition:

int main() {
    pthread_mutex_t m;
    pthread_cond_t c;
    pthread_mutex_init(&m, NULL);
    pthread_cond_init(&c, NULL);
    /* signal & wait */
    pthread_cond_signal(&c);
    pthread_mutex_lock(&m); /* hangs here, since signal is missed. */
    pthread_cond_wait(&c, &m);
    pthread_mutex_unlock(&m);
    /* destroy */
    pthread_mutex_destroy(&m);
    pthread_cond_destroy(&c);
    return 0;
}

int main() {

pthread_mutex_t m;

pthread_cond_t c;

pthread_mutex_init(&m, NULL);

pthread_cond_init(&c, NULL);

/* signal & wait */

pthread_cond_signal(&c);

pthread_mutex_lock(&m); /* hangs here, since signal is missed. */

pthread_cond_wait(&c, &m);

pthread_mutex_unlock(&m);

/* destroy */

pthread_mutex_destroy(&m);

pthread_cond_destroy(&c);

return 0;

}

But under Windows, code below simply pass through:

int main() {
    HANDLE e = CreateEvent(NULL, FALSE, FALSE, NULL);
    SetEvent(e);
    WaitForSingleObject(e, INFINITE); /* won't miss. */
    return 0;
}

int main() {

HANDLE e = CreateEvent(NULL, FALSE, FALSE, NULL);

SetEvent(e);

WaitForSingleObject(e, INFINITE); /* won't miss. */

return 0;

}

And, under Windows Vista and later versions, a new series of synchronization API was introduced to align with the Linux API:

int main() { /* requires windows vista and later. */
    CRITICAL_SECTION cs;
    CONDITION_VARIABLE cv;
    InitializeCriticalSection(&cs);
    InitializeConditionVariable(&cv);
    /* signal & wait */
    WakeConditionVariable(&cv);
    EnterCriticalSection(&cs);
    SleepConditionVariableCS(&cv, &cs, INFINITE); /* hangs here, since signal is missed. */
    LeaveCriticalSection(&cs);
    /* destroy */
    DeleteCriticalSection(&cs);
    return 0;
}

int main() { /* requires windows vista and later. */

CRITICAL_SECTION cs;

CONDITION_VARIABLE cv;

InitializeCriticalSection(&cs);

InitializeConditionVariable(&cv);

/* signal & wait */

WakeConditionVariable(&cv);

EnterCriticalSection(&cs);

SleepConditionVariableCS(&cv, &cs, INFINITE); /* hangs here, since signal is missed. */

LeaveCriticalSection(&cs);

/* destroy */

DeleteCriticalSection(&cs);

return 0;

}

Spurious Wakeups

November 20, 2014 by gonwan·0 Comments

http://vladimir_prus.blogspot.com/2005/07/spurious-wakeups.html

One of the two basic synchronisation primitives in multithreaded programming is called “condition variables”. Here’s a small example:

bool something_happened;
boost::mutex m;
boost::condition_variable c;
void thread1() {
    boost::mutex::scoped_lock(m);
    while (!something_happened) {
        c.wait(m);
    }
}
void thread2() {
    // do lots of work
    boost::mutex::scoped_lock(m);
    something_happened = true;
    c.notify_one();
}

bool something_happened;

boost::mutex m;

boost::condition_variable c;

void thread1() {

boost::mutex::scoped_lock(m);

while (!something_happened) {

c.wait(m);

}

void thread2() {

// do lots of work

boost::mutex::scoped_lock(m);

something_happened = true;

c.notify_one();

}

Here, the call to “c.wait()” unlocks the mutex (allowing the other thread to eventually lock it), and suspends the calling thread. When another thread calls ‘notify’, the first thread wakes up, locks the mutex again (implicitly, inside ‘wait’), sees that variable is set to ‘true’ and goes on.

But why do we need the while loop, can’t we write:

    if (!something_happened) {
        c.wait(m);
    }

if (!something_happened) {

c.wait(m);

}

We can’t. And the killer reason is that ‘wait’ can return without any ‘notify’ call. That’s called spurious wakeup and is explicitly allowed by POSIX. Essentially, return from ‘wait’ only indicates that the shared data might have changed, so that data must be evaluated again.

Okay, so why this is not fixed yet? The first reason is that nobody wants to fix it. Wrapping call to ‘wait’ in a loop is very desired for several other reasons. But those reasons require explanation, while spurious wakeup is a hammer that can be applied to any first year student without fail.

The second reason is that fixing this is supposed to be hard. Most sources I’ve seen say that fixing that would require very large overhead on certain architectures. Strangely, no details were ever given, which made me wonder if avoiding spurious wakeups is simple, but all the threading experts secretly decided to tell everybody it’s hard.

After asking on comp.programming.thread, I at least know the reason for Linux (thanks to Ben Hutchings). Internally, wait is implemented as a call to the ‘futex’ system call. Each blocking system call on Linux returns abruptly when the process receives a signal — because calling signal handler from kernel call is tricky. What if the signal handler calls some other system function? And a new signal arrives? It’s easy to run out of kernel stack for a process. Exactly because each system call can be interrupted, when glibc calls any blocking function, like ‘read’, it does it in a loop, and if ‘read’ returns EINTR, calls ‘read’ again.

Can the same trick be used to conditions? No, because the moment we return from ‘futex’ call, another thread can send us notification. And since we’re not waiting inside ‘futex’, we’ll miss the notification(A third thread can get it, and change the value of predicate. — gonwan). So, we need to return to the caller, and have it reevaluate the predicate. If another thread indeed set it to true, we’ll break out of the loop.

So much for spurious wakeups on Linux. But I’m still very interested to know what the original reasons were.

==============================
Also see the explanation for spurious wakeups on the linux man page: pthread_cond_signal.
Last note: PulseEvent() in windows(manual-reset) = pthread_cond_signal() in linux, while SetEvent() in windows(auto-reset) = pthread_cond_broadcast() in linux, see here and here. And spurious wakeups are also possible on windows when using condition variables.

0x2B|~0x2B

My broken wings still strong enough to cross the ocean with.

Author: gonwan

std::thread and std::future in C++11

1. std::thread

2. std::mutex and std::condition_variable

3. std::future with std::async()

4. std::future with std::packaged_task

5. std::future with std::promise

Two-phase Lookup in C++ Templates

Switching to the Linuxmint 17.1 Theme

Different Semantics Between Win32 Events and Condition Variables

Spurious Wakeups