How can I have non-static thread-local variable for each instance

Question

The problem itself:

class B{/*...*/};
class A {
    /* members */
    NON-static thread_local B var; // and a thread_local variable here
    ret_t method(/* args */);
};

I want var to exist independently each thread and each instance.

The larger (complete) problem:

Instances of A are shared across threads. B is some resource necessary to call A::method, and it must be independent with respect to threads to avoid race condition (that is, A::method must have "write access" to var). And the corresponding B are different for different instances of A.

One not fully satisfactory approach I came up with is to have some container (say std::unordered_map<THREAD_IDENTIFIER_TYPE, B>) to store each var corresponding to each thread per instance. However, this neither limit access to vars across threads nor prevent the whole container from being modified. (So that require developer to be careful enough to write safe code.)

---

I've seen a few post on java ThreadLocal keyword(?) on SO, but none of them seem to provide idea that really works. Any suggestion?

Answer 1

You can't have a non-static member declared thread_local. See cppreference. In particular:

the thread_local keyword is only allowed for objects declared at namespace scope, objects declared at block scope, and static data members.

If you don't want to use pthreads (tricky on Windows), some container is your only option.

One choice is a variant of std::unordered_map<THREAD_IDENTIFIER_TYPE, B>. (You could write a class to wrap it and protect the map with a mutex.)

Another initially attractive option is a thread_local static member of A which maps A* to B will avoid any need for locks.

class A {
    static thread_local std::unordered_map<A*, B> s_B;
    ....
};

usage:

void A::foo() {
    B& b = s_B[this];  // B needs to be default constructable.
    ...

The catch is that you need some way to remove elements from the s_B map. That's not too much of a problem if A objects are actually locked to a particular thread, or if you have some way to invoke functions on another thread - but it's not entirely trivial either. (You may find it safer to use a unique identifier for A which is an incrementing 64-bit counter - that way there is much less risk of the identifier being reused between destroying the A object and the message to remove the B from all the maps being processed.)