Are C++ exceptions sufficient to implement thread-local storage?

Question

I was commenting on an answer that thread-local storage is nice and recalled another informative discussion about exceptions where I supposed

The only special thing about the execution environment within the throw block is that the exception object is referenced by rethrow.

Putting two and two together, wouldn't executing an entire thread inside a function-catch-block of its main function imbue it with thread-local storage?

It seems to work fine, albeit slowly. Is this novel or well-characterized? Is there another way of solving the problem? Was my initial premise correct? What kind of overhead does get_thread incur on your platform? What's the potential for optimization?

#include <iostream>
#include <pthread.h>
using namespace std;

struct thlocal {
    string name;
    thlocal( string const &n ) : name(n) {}
};

struct thread_exception_base {
    thlocal &th;
    thread_exception_base( thlocal &in_th ) : th( in_th ) {}
    thread_exception_base( thread_exception_base const &in ) : th( in.th ) {}
};

thlocal &get_thread() throw() {
    try {
        throw;
    } catch( thread_exception_base &local ) {
        return local.th;
    }
}

void print_thread() {
    cerr << get_thread().name << endl;
}

void *kid( void *local_v ) try {
    thlocal &local = * static_cast< thlocal * >( local_v );
    throw thread_exception_base( local );
} catch( thread_exception_base & ) {
    print_thread();

    return NULL;
}

int main() {
    thlocal local( "main" );
    try {
        throw thread_exception_base( local );
    } catch( thread_exception_base & ) {
        print_thread();

        pthread_t th;
        thlocal kid_local( "kid" );
        pthread_create( &th, NULL, &kid, &kid_local );
        pthread_join( th, NULL );

        print_thread();
    }

    return 0;
}

This does require defining new exception classes derived from thread_exception_base, initializing the base with get_thread(), but altogether this doesn't feel like an unproductive insomnia-ridden Sunday morning…

EDIT: Looks like GCC makes three calls to pthread_getspecific in get_thread. EDIT: and a lot of nasty introspection into the stack, environment, and executable format to find the catch block I missed on the first walkthrough. This looks highly platform-dependent, as GCC is calling some libunwind from the OS. Overhead on the order of 4000 cycles. I suppose it also has to traverse the class hierarchy but that can be kept under control.

Thielen

Is a function try/catch block allowed for main? – Grasmere

Most certainly—the standard specifies that main's catch block doesn't handle throws from global/static constructors. Not that it's essential to this mechanism. – Thielen

What happens if a second exception is thrown? – Whitehorse

@jdv: Every exception class needs to be derived from thlocal and that base always needs to be initialized with get_thread(). Hmm, sounds like I need an intermediate pointer in there to avoid copying data. – Thielen

+1 This is an awesome hack and bit of lateral thinking. – Lukelukens

Answer 1

In the playful spirit of the question, I offer this horrifying nightmare creation:

class tls
{
    void push(void *ptr)
    {
        // allocate a string to store the hex ptr 
        // and the hex of its own address
        char *str = new char[100];
        sprintf(str, " |%x|%x", ptr, str);
        strtok(str, "|");
    }

    template <class Ptr>
    Ptr *next()
    {
        // retrieve the next pointer token
        return reinterpret_cast<Ptr *>(strtoul(strtok(0, "|"), 0, 16));
    }

    void *pop()
    {
        // retrieve (and forget) a previously stored pointer
        void *ptr = next<void>();
        delete[] next<char>();
        return ptr;
    }

    // private constructor/destructor
    tls() { push(0); }
    ~tls() { pop(); }

public:
    static tls &singleton()
    {
        static tls i;
        return i;
    }

    void *set(void *ptr)
    {
        void *old = pop();
        push(ptr);
        return old;
    }

    void *get()
    {
        // forget and restore on each access
        void *ptr = pop();
        push(ptr);
        return ptr;
    }
};

Taking advantage of the fact that according to the C++ standard, strtok stashes its first argument so that subsequent calls can pass 0 to retrieve further tokens from the same string, so therefore in a thread-aware implementation it must be using TLS.

example *e = new example;

tls::singleton().set(e);

example *e2 = reinterpret_cast<example *>(tls::singleton().get());

So as long as strtok is not used in the intended way anywhere else in the program, we have another spare TLS slot.

Lukelukens

strtok is defined in terms of a sequence of calls, so it's ambiguous whether a thread-aware implementation keeps a TLS pointer or a global with a mutex. I am horrified, though. – Thielen

I'm glad it had the desired effect! :) If strtok was only protected by a mutex that would be locked for each call, that wouldn't really help, so TLS is the only likely solution. Though I suppose it could have some perverted use as a semi-reliable communication channel between threads! And on top of that I could build a stream interface, like TCP over IP... Now there's a challenge! – Lukelukens

This is the code that haunts the demon that haunts the people in Paranormal Activity. – Blintz

Answer 2

I think you're onto something here. This might even be a portable way to get data into callbacks that don't accept a user "state" variable, as you've mentioned, even apart from any explicit use of threads.

So it sounds like you've answered the question in your subject: YES.

Churlish

Answer 3

void *kid( void *local_v ) try {
    thlocal &local = * static_cast< thlocal * >( local_v );
    throw local;
} catch( thlocal & ) {
    print_thread();

    return NULL;
}

==

void *kid (void *local_v ) { print_thread(local_v); }

I might be missing something here, but it's not a thread local storage, just unnecessarily complicated argument passing. Argument is different for each thread only because it is passed to pthread_create, not because of any exception juggling.

---

It turned out that I indeed was missing that GCC is producing actual thread local storage calls in this example. It actually makes the issue interesting. I'm still not quite sure whether it is a case for other compilers, and how is it different from calling thread storage directly.

I still stand by my general argument that the same data can be accessed in a more simple and straight-forward way, be it arguments, stack walking or thread local storage.

Rocky

Thread local storage is just complicated argument passing. get_thread retrieves the argument from any unknown location up the call stack. pthread_create isn't special, cf main. The significance here is that it works for functions without arguments, such as destructors or ill-designed callbacks. – Thielen

Exactly - but it doesn't work for function without arguments! You have to explicitly pass it to function by throw-ing before call. It's just that function(arguments) becomes throw arguments ... function. – Rocky

I also don't think it's entirely correct to call pthread_getspecific "argument passing", no more than stack pointer itself. – Rocky

@ima: print_thread is as without-arguments as functions get in C++. The intent is only one throw local; at the topmost scope. In terms of the functional language formalism, all data movement is argument passing. Can you give an example of something that should be possible but isn't? – Thielen

One? Your example has 3 'throw local's, one for each call. Consider: you can declare function without arguments, and then push and pop arguments in stack manually - would it make a parameter-less function? Obviously no, just one with a custom calling convention. You are using exception objects as a custom stack implementation, and store parameters there. And why are we talking about functional language formalism here? – Rocky

Providing example is tricky, because thread local storage itself is never required, it's just a convenience. – Rocky

But I think if you rewrite your example to use a more complex function call graph, with trees- and loops-, you'll see that it's equivalent to passing (void*) to every function. – Rocky

There are clearly two throw local, one for each thread. I can retrieve the exception object any number of times with get_thread, so it's not like a stack. The functional formalism is relevant because it relates data flow to argument passing. get_thread pulls an argument "out of thin air". Copy my code and try it yourself. – Thielen

My mistake, two throw local and one throw - it doesn't matter much here though. "So it's not like a stack" - it's not "like", it "is" a stack. Where do you think thread_exception_base objects are stored? Check disassembly if you doubt. You are using exception handlers to access stack instead of more conventional means, it doesn't give any new capabilities, just a stack. – Rocky

@ima; the point is, 'throw' on its own, picks up the exception currently being handled, regardless how far up the stack it was "caught", so you don't need to pass it, there may very well be frames on the stack without this 'void*' argument. – Fairchild

In a sense, what you have here is platform-independent way of stack walking. I can even imagine where it might be useful (rarely, since practical threads api's themselves are not cross-platform), but it's quite a different thing from thread local storage. – Rocky

@ima: I did check the disassembly and found it was calling pthread_getspecific. See the edit to the question. There is an exception stack but I'm only using one level of it. The call stack is not traversed by get_thread, at least not under GCC. – Thielen

Looks like I were wrong here, sorry for being stubborn. Completely unexpected though, why would GCC use thread local storage for exception? I'll have to look into it. It begs another question though - if it is the case, why not just call getspecific directly? – Rocky

It's probably combination, it might be calling getspecific to limit stack walking to the function call that started process. Because exception object itself is definitely stored on stack, and the same exception can be thrown deep inside thread calls. – Rocky

@ima: I agree, it's possible to implement exceptions without getspecific by walking the stack. getspecific is simply faster. By the same token, getspecific could also be implemented by stack-walk… the functionality is equivalent. However, I don't know another way to do it portably. (If you do, I'll probably select your answer.) One direct call to getspecific would of course be a lot faster, but this way I can write code that still works on single-threaded or non-pthread platforms. – Thielen

No worries about stubbornness. I'm glad you articulated your thoughts and arguments and hope you don't delete this. – Thielen

Answer 4

Accessing data on the current function call stack is always thread safe. That's why your code is thread safe, not because of the clever use of exceptions. Thread local storage allows us to store per-thread data and reference it outside of the immediate call stack.

Footling

Data on the call stack is quite unsafe if used in an unsafe manner. Thread local storage is not inherently safer than anything else, it's simply keyed by thread. – Thielen

This has nothing to do with thread safety, only thread local storage. – Fairchild

If you declared a bit of data on the stack and then passed it around to every function as an extra argument, you'd effectively have thread-local storage. The advantage of TLS is that you don't have to add the extra argument. The clever thing about this idea is noting that you can say void foo() { throw; }, where throw has no local context to determine what it should be throwing, so the runtime has to keep one per call stack, which is to say, one per thread. Hence this is a way of sharing a value only within a thread without using parameters to pass it around. Just like TLS. – Lukelukens

My original comment did contain a serious error which I consider a typo, but you be the judge. In any case I apologize for the confusion; I've corrected the error. I still don't understand how exceptions can take the place of thread local storage. There's no scenario I can thing of where passing stack variables to functions on or off the current thread will create per-thread variable instance, which is what thread local storage is. – Footling

This isn't stack variables. It's a storage slot provided by the C++ runtime library, which is used to store the most recently caught exception so that throw; will be able to retrieve it and rethrow it. The gag here is to store arbitrary data in an exception object, use throw/catch to get that exception stored in the slot, and then use throw; to retrieve it elsewhere. Hence it is a "global" storage slot... – Lukelukens

... But in a C++ implementation that is extended to support threads, it must be changed to a thread-local storage slot, otherwise thread 1 might inadvertantly rethrow something that has just been caught in thread 2, instead of rethrowing what was just caught in thread 1. – Lukelukens