26

我正在评论一个线程本地存储很好的答案，并回忆起另一个关于我认为的异常的信息性讨论

throw 块中的执行环境唯一的特殊之处是异常对象被 rethrow 引用。

将两个和两个放在一起，不会在其主函数的函数捕获块内执行整个线程，并为其注入线程本地存储吗？

它似乎工作正常，虽然速度很慢。这本小说还是有特色的？是否有另一种解决问题的方法？我最初的前提是正确的吗？get_thread您的平台会产生什么样的开销？优化的潜力是什么？

#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;
}

这确实需要定义从 派生的新异常类thread_exception_base，用 初始化基类get_thread()，但总的来说，这不像是周日早上失眠的低效……</p>

编辑：看起来 GCC对in进行了三个调用。编辑：对堆栈、环境和可执行格式进行了大量令人讨厌的内省，以找到我在第一次演练中错过的块。这看起来高度依赖于平台，因为 GCC 正在从操作系统调用一些。大约 4000 个周期的开销。我想它还必须遍历类层次结构，但这可以保持在控制之下。pthread_getspecificget_threadcatchlibunwind

4

4 回答 4

10

本着这个问题的俏皮精神，我提供了这个可怕的噩梦创作：

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;
    }
};

利用根据 C++ 标准strtok隐藏其第一个参数的事实，以便后续调用可以传递0以从同一字符串中检索更多令牌，因此在线程感知实现中它必须使用 TLS。

example *e = new example;

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

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

因此，只要strtok在程序的其他任何地方都没有以预期的方式使用，我们就有另一个备用 TLS 插槽。

于 2010-07-02T15:09:37.260 回答
3

我认为你在这里有所作为。正如您所提到的，这甚至可能是一种将数据放入不接受用户“状态”变量的回调的可移植方式，即使除了任何显式使用线程。

所以听起来你已经回答了你的主题中的问题：是的。

于 2010-03-21T18:01:33.140 回答
0 
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); }

我可能在这里遗漏了一些东西，但它不是线程本地存储，只是不必要的复杂参数传递。每个线程的参数不同只是因为它被传递给 pthread_create，而不是因为任何异常处理。

事实证明，在这个例子中，我确实错过了 GCC 正在产生实际的线程本地存储调用。它实际上使这个问题变得有趣。我仍然不太确定它是否适用于其他编译器，以及它与直接调用线程存储有什么不同。

我仍然坚持我的一般论点，即可以以更简单直接的方式访问相同的数据，无论是参数、堆栈遍历还是线程本地存储。

于 2010-03-21T15:52:04.167 回答
0

访问当前函数调用堆栈上的数据始终是线程安全的。这就是为什么您的代码是线程安全的，而不是因为巧妙地使用了异常。线程本地存储允许我们存储每个线程的数据并在立即调用堆栈之外引用它。

于 2010-03-21T17:37:40.010 回答