What is the purpose of this pattern using a volatile pointer to "this"?

Question

I have recently come across a curious use of the volatile keyword in C++ multithreaded code. To abstract the programming pattern, let's assume there is a control object which is accessed by one producer and several consumer threads:

class control_t {
    pthread_mutex_t control_lock;
    pthread_cond_t wake_cond;
    bool there_is_work_todo;

    control_t volatile* vthis() { return this; }
}

The consumer thread does the following (c is a non-volatile pointer to the control object):

...
pthread_mutex_lock(c->control_lock)
while (!c->vthis()->there_is_work_todo) {
    pthread_cond_wait(&c->wake_cond, &c->control_lock);
}
...

The idea here is that the consumer threads will wait until there is some work to be done, which the producer signalizes via the wake_cond variable.

What I don't understand here is why the control object is accessed through a volatile pointer to "this", which is returned by the method vthis(). Why is that?

Answer 1

The use of volatile in multi-threaded code is generally suspect. volatile was designed to avoid optimizing out reads and writes to memory, which is useful when such reads and writes occur on special addresses that map to hardware registers. See, for example, how volatile is useless to prevent data-races, and how it can be (ab)used as a phantom type...

Since the author used proper synchronization (mutexes and condition variables), the use of of volatile is extremely suspect. Such uses generally stem from a misunderstanding, most notably spread by languages such as Java who reused the same keyword with different semantics.

In C and C++, multi-threaded code should rely on memory barriers, such as those introduced by the mutexes and atomic operations, which guarantee that the values are correctly synchronized across the different CPU cores and caches.

Answer 2

The use of volatile in this code yields either undefined behavior or is redundant:

1. If the object pointed to by c is not volatile, then accesses (including reads) with the addition of volatile is statically deemed as causing a side effect (to accomodate cases where the compiler cannot statically find out whether an access really uses a volatile object), but is not required to be carried out at all costs, since the side effect on the nonvolatile object does not constitute observable behavior.

2. If the object that you call vthis on is volatile, then the code has undefined behavior because it accesses a volatile object through an lvalue of nonvolatile type before that call in the previous lines.

The code probably relies on an implementation not optimizing away the volatile access because of compatibility with existing code.