[boost] [threadalert] alternative design for thread_member_ptr and thread preamble

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