Subject: [boost] [threadalert] alternative design for thread_member_ptr and thread preamble
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-09-28 17:04:10
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
* 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
* I have renamed boostex::thread::init by boost::thread_preamble, and these
preamble functions will be called on the threads initialized using the
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:
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:
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk