Is there a boost equivalent to this "safe_read" call

Question

I am new to boost threading (came from Win32 threading, which has probably ruined me).

So I'm trying to make a more "RAII" way to check that the working loop should still be going. So I made this simple function:

template<typenameT> 
T safe_read(const T& t,boost::mutex& mutex)
{
    boost::interprocess::scoped_lock lock(mutex);
    return t;
}

Is there a boost equivalent to this, since it seems like I'd use this all the time? Also it this an acceptable call?

The idea is to be able to safely do this without using a weirder lock:

while(!safe_read(this->is_killing_,this->is_killing_mutex_))
{
    DoWork();
}

A boolean is either going to be true or false, no matter whether you lock it or not. What happens when you exit the `safe_access` call? — Nick, May 09 '13 at 15:10
@Nick, The lock is there because the boolean is being changed from another thread. So if a separate thread changes the boolean while the while reads it, the behavior is "undefined". Most computers probably have enough sync controls in their memory model to take care of that, but I don't trust it. — IdeaHat, May 09 '13 at 15:16
@hmjd I was not, that looks like a much cleaner solution, I think that's the answer! — IdeaHat, May 09 '13 at 15:31
@Nick: Untrue. In reality, in the absence of a mutex, boolean can be both true **and** false, simply by being in two distinct caches. — MSalters, May 09 '13 at 16:33
But I suppose that in the situation above, all that is going to happen is that `DoWork()` is going to be called more than it should - which could very well happen even with a mutex. — Nick, May 09 '13 at 21:55

score 3 · Accepted Answer · answered May 09 '13 at 15:35

3

boost::atomic<bool> was added in boost v1.53.0, based on c++11 std::atomics. For example:

#include <boost/atomic.hpp>

boost::atomic<bool> is_killing (false);

while (!is_killing)
{
}

This would eliminate the explicit mutex and the safe_access function from the code, providing the synchronization required.

answered May 09 '13 at 15:35

hmjd

That actually works well for this! The follow up is a slightly different instance, where I want to be able to lock a group of variables...is doing 'atomic' kosher? – IdeaHat May 09 '13 at 16:05
@MadScienceDreams, see the [limitations](http://www.boost.org/doc/libs/1_53_0_beta1/doc/html/atomic/limitations.html) section. – hmjd May 09 '13 at 16:09
yeah it looks like its not worth it. But it think you can make a lock_guard off of an atomic (have to double check). – IdeaHat May 09 '13 at 16:16
@MadScienceDreams: If that struct is a set of flags, it might be worth to pack them in a single integral type which can be atomic. – MSalters May 09 '13 at 16:31

score 0 · Answer 2 · answered May 09 '13 at 15:08

0

I don't think it works the way you think it does, because once the safe_access function returns, the lock is released.

answered May 09 '13 at 15:08

W.B.

That's what I want actually. Because t is being read in by reference but being pass out by value, this call essentially makes a snapshot copy of T and return it, releasing the lock after the safe_access returns. – IdeaHat May 09 '13 at 15:20

2 Answers2