多线程编程中还有一个重要的概念:Thread Local Store(TLS,线程局部存储),在boost中,TLS也被称作TSS,Thread Specific Storage。
boost ::thread库为我们提供了一个接口简单的TLS的面向对象的封装,以下是tss类的接口定义:
class tss
{
public :
tss (boost ::function1 < void , void *>* pcleanup );
void * get () const ;
void set ( void * value );
void cleanup ( void * p );
};
分别用于获取、设置、清除线程局部存储变量,这些函数在内部封装了TlsAlloc、TlsGetValue、TlsSetValue等API操作,将它们封装成了OO的形式。
但boost将该类信息封装在detail名字空间内,即不推荐我们使用,当需要使用tss时,我们应该使用另一个使用更加方便的类:thread_specific_ptr,这是一个智能指针类,该类的接口如下:
class thread_specific_ptr : private boost ::noncopyable // Exposition only
{
public :
// construct/copy/destruct
thread_specific_ptr ();
thread_specific_ptr ( void (*cleanup )( void *));
~thread_specific_ptr ();
// modifier functions
T * release ();
void reset (T * = 0 );
// observer functions
T * get () const ;
T * operator ->() const ;
T & operator *()() const ;
};
即可支持get、reset、release等操作。
thread_specific_ptr类的实现十分简单,仅仅为了将tss类“改装”成智能指针的样子,该类在其构造函数中会自动创建一个tss对象,而在其析构函数中会调用默认参数的reset函数,从而引起内部被封装的tss对象被析构,达到“自动”管理内存分配释放的目的。
以下是一个运用thread_specific_ptr实现TSS的例子:
#include <boost/thread/thread.hpp>
#include <boost/thread/mutex.hpp>
#include <boost/thread/tss.hpp>
#include <iostream>
boost ::mutex io_mutex ;
boost ::thread_specific_ptr < int > ptr ; // use this method to tell that this member will not shared by all threads
struct count
{
count ( int id ) : id (id ) { }
void operator ()()
{
if (ptr .get () == 0 ) // if ptr is not initialized, initialize it
ptr .reset ( new int ( 0 )); // Attention, we pass a pointer to reset (actually set ptr)
for ( int i = 0 ; i < 10 ; ++i )
{
(*ptr )++;
boost ::mutex ::scoped_lock lock (io_mutex );
std ::cout << id << ": " << *ptr << std ::endl ;
}
}
int id ;
};
int main ( int argc , char * argv [])
{
boost ::thread thrd1 (count ( 1 ));
boost ::thread thrd2 (count ( 2 ));
thrd1 .join ();
thrd2 .join ();
return 0 ;
}
此外,thread库还提供了一个很有趣的函数,call_once,在tss ::init的实现中就用到了该函数。
该函数的声明如下:
void call_once ( void (*func )(), once_flag & flag );
该函数的Windows实现通过创建一个Mutex使所有的线程在尝试执行该函数时处于等待状态,直到有一个线程执行完了func函数,该函数的第二个参数表示函数func是否已被执行,该参数往往被初始化成BOOST_ONCE_INIT(即 0),如果你将该参数初始化成 1,则函数func将不被调用,此时call_once相当于什么也没干,这在有时候可能是需要的,比如,根据程序处理的结果决定是否需要call_once某函数func。
call_once在执行完函数func后,会将flag修改为 1,这样会导致以后执行call_once的线程(包括等待在Mutex处的线程和刚刚进入call_once的线程)都会跳过执行func的代码。
需要注意的是,该函数不是一个模板函数,而是一个普通函数,它的第一个参数 1是一个函数指针,其类型为 void (*)(),而不是跟boost库的很多其它地方一样用的是function模板,不过这样也没有关系,有了boost ::bind这个超级武器,想怎么绑定参数就随你的便了,根据boost的文档,要求传入的函数不能抛出异常,但从实现代码中好像不是这样。
以下是一个典型的运用call_once实现一次初始化的例子:
#include <boost/thread/thread.hpp>
#include <boost/thread/once.hpp>
#include <iostream>
int i = 0 ;
int j = 0 ;
boost ::once_flag flag = BOOST_ONCE_INIT ;
void init ()
{
++i ;
}
void thread ()
{
boost ::call_once (&init , flag );
++j ;
}
int main ( int argc , char * argv [])
{
boost ::thread thrd1 (&thread );
boost ::thread thrd2 (&thread );
thrd1 .join ();
thrd2 .join ();
std ::cout << i << std ::endl ;
std ::cout << j << std ::endl ;
return 0 ;
}
结果显示,全局变量i仅被执行了一次 ++操作,而变量j则在两个线程中均执行了 ++操作。
其它
boost ::thread目前还不十分完善,最主要的问题包括:没有线程优先级支持,或支持线程的取消操作等,而且,目前的实现机制似乎不大容易通过简单修改达到这一要求,也许将来的某个版本会在实现上出现较大调整,但目前支持的接口应该会相对保持稳定,目前支持的特性也还会继续有效。
boost ::thread库为我们提供了一个接口简单的TLS的面向对象的封装,以下是tss类的接口定义:
class tss
{
public :
tss (boost ::function1 < void , void *>* pcleanup );
void * get () const ;
void set ( void * value );
void cleanup ( void * p );
};
分别用于获取、设置、清除线程局部存储变量,这些函数在内部封装了TlsAlloc、TlsGetValue、TlsSetValue等API操作,将它们封装成了OO的形式。
但boost将该类信息封装在detail名字空间内,即不推荐我们使用,当需要使用tss时,我们应该使用另一个使用更加方便的类:thread_specific_ptr,这是一个智能指针类,该类的接口如下:
class thread_specific_ptr : private boost ::noncopyable // Exposition only
{
public :
// construct/copy/destruct
thread_specific_ptr ();
thread_specific_ptr ( void (*cleanup )( void *));
~thread_specific_ptr ();
// modifier functions
T * release ();
void reset (T * = 0 );
// observer functions
T * get () const ;
T * operator ->() const ;
T & operator *()() const ;
};
即可支持get、reset、release等操作。
thread_specific_ptr类的实现十分简单,仅仅为了将tss类“改装”成智能指针的样子,该类在其构造函数中会自动创建一个tss对象,而在其析构函数中会调用默认参数的reset函数,从而引起内部被封装的tss对象被析构,达到“自动”管理内存分配释放的目的。
以下是一个运用thread_specific_ptr实现TSS的例子:
#include <boost/thread/thread.hpp>
#include <boost/thread/mutex.hpp>
#include <boost/thread/tss.hpp>
#include <iostream>
boost ::mutex io_mutex ;
boost ::thread_specific_ptr < int > ptr ; // use this method to tell that this member will not shared by all threads
struct count
{
count ( int id ) : id (id ) { }
void operator ()()
{
if (ptr .get () == 0 ) // if ptr is not initialized, initialize it
ptr .reset ( new int ( 0 )); // Attention, we pass a pointer to reset (actually set ptr)
for ( int i = 0 ; i < 10 ; ++i )
{
(*ptr )++;
boost ::mutex ::scoped_lock lock (io_mutex );
std ::cout << id << ": " << *ptr << std ::endl ;
}
}
int id ;
};
int main ( int argc , char * argv [])
{
boost ::thread thrd1 (count ( 1 ));
boost ::thread thrd2 (count ( 2 ));
thrd1 .join ();
thrd2 .join ();
return 0 ;
}
此外,thread库还提供了一个很有趣的函数,call_once,在tss ::init的实现中就用到了该函数。
该函数的声明如下:
void call_once ( void (*func )(), once_flag & flag );
该函数的Windows实现通过创建一个Mutex使所有的线程在尝试执行该函数时处于等待状态,直到有一个线程执行完了func函数,该函数的第二个参数表示函数func是否已被执行,该参数往往被初始化成BOOST_ONCE_INIT(即 0),如果你将该参数初始化成 1,则函数func将不被调用,此时call_once相当于什么也没干,这在有时候可能是需要的,比如,根据程序处理的结果决定是否需要call_once某函数func。
call_once在执行完函数func后,会将flag修改为 1,这样会导致以后执行call_once的线程(包括等待在Mutex处的线程和刚刚进入call_once的线程)都会跳过执行func的代码。
需要注意的是,该函数不是一个模板函数,而是一个普通函数,它的第一个参数 1是一个函数指针,其类型为 void (*)(),而不是跟boost库的很多其它地方一样用的是function模板,不过这样也没有关系,有了boost ::bind这个超级武器,想怎么绑定参数就随你的便了,根据boost的文档,要求传入的函数不能抛出异常,但从实现代码中好像不是这样。
以下是一个典型的运用call_once实现一次初始化的例子:
#include <boost/thread/thread.hpp>
#include <boost/thread/once.hpp>
#include <iostream>
int i = 0 ;
int j = 0 ;
boost ::once_flag flag = BOOST_ONCE_INIT ;
void init ()
{
++i ;
}
void thread ()
{
boost ::call_once (&init , flag );
++j ;
}
int main ( int argc , char * argv [])
{
boost ::thread thrd1 (&thread );
boost ::thread thrd2 (&thread );
thrd1 .join ();
thrd2 .join ();
std ::cout << i << std ::endl ;
std ::cout << j << std ::endl ;
return 0 ;
}
结果显示,全局变量i仅被执行了一次 ++操作,而变量j则在两个线程中均执行了 ++操作。
其它
boost ::thread目前还不十分完善,最主要的问题包括:没有线程优先级支持,或支持线程的取消操作等,而且,目前的实现机制似乎不大容易通过简单修改达到这一要求,也许将来的某个版本会在实现上出现较大调整,但目前支持的接口应该会相对保持稳定,目前支持的特性也还会继续有效。