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