Действительно ли исключения C++ достаточны для реализации локальной памяти потока?
Я комментировал ответ, что локальная память потока хороша и вспомнила другую информативную дискуссию об исключениях, где я предположил
Единственная специальная вещь о среде выполнения в блоке броска состоит в том, что на объект исключения ссылается перебросок.
При соединении два и два, не был бы, выполняя весь поток в функциональном блоке выгоды его основной функции, пропитывают его с локальной памятью потока?
Это, кажется, хорошо работает, хотя медленно. Это ново или хорошо охарактеризовано? Есть ли другой способ решить проблему? Моя начальная предпосылка была корректна? Какой наверху делает get_thread подвергнуться на своей платформе? Каков потенциал для оптимизации?
#include
#include
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(), но в целом это не чувствует себя подобно непроизводительному находящемуся во власти бессонницей утру воскресенья …
Править: Похож на GCC, выполняет три вызова к pthread_getspecific в get_thread.Править: и большой противный самоанализ в стек, среду и формат исполняемых файлов для нахождения catch блок я отсутствовал на первой пошаговой демонстрации. Это выглядит очень зависимым от платформы, как GCC называет некоторых libunwind от ОС. Наверху на порядке 4 000 циклов. Я предполагаю, что это также должно пересечь иерархию классов, но это может держаться под контролем.
4 ответа
В шутливом духе вопроса я предлагаю этот ужасающий кошмар:
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.
Я думаю, вы кое-что заметили. Это может быть даже переносимый способ получения данных в обратных вызовах, которые не принимают переменную «состояния» пользователя, как вы упомянули, даже помимо любого явного использования потоков.
Похоже, вы ответили на вопрос в своей теме: ДА.
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 в этом примере производит фактические вызовы локального хранилища потоков. Это действительно делает вопрос интересным. Я до сих пор не совсем уверен, относится ли это к другим компиляторам и чем он отличается от прямого вызова хранилища потоков.
Я по-прежнему придерживаюсь своего общего аргумента, что к одним и тем же данным можно получить доступ более простым и понятным способом, будь то аргументы, обход стека или локальное хранилище потоков.
Доступ к данным в стеке вызовов текущей функции всегда потокобезопасен. Именно поэтому ваш код является потокобезопасным, а не из-за умного использования исключений. Локальное хранилище потоков позволяет нам хранить данные для каждого потока и ссылаться на них вне стека немедленных вызовов.