Hello, I have do some refactoring on the thdmbrptr.hpp and thdmbrptr.cpp files. * The design is now more decoupled, separating the thread preamble initialization and the thread_member_ptr type. * The thread_member_ptr constructor supports now a cleanup functions parameter. * I have added the release function * We don't need any more a new class thread (boostex::thread) that inherits from boost::thread, to store the common context for the thread to manage the detaching of the pointer from the map (this is done using the thread_specific_ptr cleanup). * I have renamed boostex::thread::init by boost::thread_preamble, and these preamble functions will be called on the threads initialized using the thread_preamble::proxy. You can find the code and example in the attached files. Just to recall the goals: * thread_preamble allows to define some preample functions which will be called by each thread initialized using the thread_preamble::proxy * thread_member_ptr: The intent of this class is to allow two threads to establish a shared memory space, without requiring the user code to pass any information. This basically does work like a thread local storage from inside the thread: boost::thread_member_ptr<myclass> pmyclass; All functions known from thread_specific_ptr are available, and so is semantics from inside the thread. Besides this another thread can get access to the data by: pmyclass[th->get_id()]->foo(); where "th" is a boost::thread* and "foo()" is a function of "myclass". The lifetime of the myclass instance is managed by a shared_ptr. One reference is held by the thread (by means of a tss), a second is held by the boost::thread object that created the thread, and additional references might be held by other threads that obtained it by "*pmyclass[th]". Please let me know what do you think of this new design. I'll use these classes for some libraries: * a software transaction library: transactional thread specific context which can also be accesible from other threads during consistency checking * a thread keep alive: the keep_alive_manager will check the registered threads by looking on the associated keep_alive thread_member_ptr. Do you think that these two classes might be a candidate to a separated Boost library or that it will be better to integrate them on the thread library? Best, Vicente