今天继续带来boost关于线程锁的一些使用，今天我使用一个更复杂的锁来控制同步，先来段简单的代码

 

#include 
    
      #include 
     
       void wait(int seconds){	boost::this_thread::sleep(boost::posix_time::seconds(seconds));}boost::timed_mutex mutex;void thread(){	for (int i = 0; i < 5; ++i)	{		wait(1);		boost::unique_lock
      
        lock(mutex, boost::try_to_lock);		if (!lock.owns_lock())			lock.timed_lock(boost::get_system_time() + boost::posix_time::seconds(1));		std::cout << "Thread " << boost::this_thread::get_id() << ": " << i << std::endl;		boost::timed_mutex *m = lock.release();		m->unlock();	}}int main(){	boost::thread t1(thread);	boost::thread t2(thread);	t1.join();	t2.join();	system("pause");}
      
     
    

 

boost::timed_mutex mutex;

boost::unique_lock<boost::timed_mutex> lock(mutex, boost::try_to_lock);

if (!lock.owns_lock())

lock.timed_lock(boost::get_system_time() + boost::posix_time::seconds(1));

上面红色部分是这次新出现的代码，这里用到的一个复杂一点的unique_lock来对程序进行加锁，使用timed_mutex对程序多线程执行部分进行保护，避免出现非预期结果。

第一个是对程序进行尝试加锁，然后再if里面对是否成功进行判断，如果不成功则延时1秒后进行加锁。好了附上程序的截图：

当然你会发现这个运行结果和前几篇中的运行结果是一样的，之所以这么使用只是为了使用这个锁而使用的，这个场景如果真得去构建的话需要更多的代码，这里只是为了告诉大家如何使用这个锁，所以就不做那么麻烦的事情，这样大家也可以专注于这个锁如何使用，而不会关心程序的其他部分导致本末倒置。下面继续详细说明下这个锁的好处，和前一次那个锁的区别：

boost::unique_lock 通过多个构造函数来提供不同的方式获得互斥体。 这个期望获得互斥体的函数简单地调用了lock() 方法，一直等到获得这个互斥体。 所以它的行为跟 boost::lock_guard 的那个是一样的。

如果第二个参数传入一个 boost::try_to_lock 类型的值，对应的构造函数就会调用 try_lock() 方法。 这个方法返回bool 型的值：如果能够获得互斥体则返回true，否则返回false 。 相比 lock() 函数，try_lock() 会立即返回，而且在获得互斥体之前不会被阻塞。

 

其实这个例子显示了三个方法获取一个互斥体：lock() 会一直等待，直到获得一个互斥体。 try_lock() 则不会等待，但如果它只会在互斥体可用的时候才能获得，否则返回 false 。 最后，timed_lock() 试图获得在一定的时间内获取互斥体。 和try_lock() 一样，返回bool 类型的值意味着成功是否。

就像 boost::lock_guard 一样， boost::unique_lock 的析构函数也会相应地释放互斥量。此外，可以手动地用unlock() 释放互斥量。也可以像上面的例子那样，通过调用 release() 解除boost::unique_lock 和互斥量之间的关联。然而在这种情况下，必须显式地调用unlock() 方法来释放互斥量，因为 boost::unique_lock 的析构函数不再做这件事情。

这个锁属于线程独占的，其他线程必须等待，直到互斥体再次被释放。