On Wednesday 26 June 2013 23:56:27 you wrote:
On Wednesday 26 June 2013 15:39:27 you wrote:
On Wed, Feb 20, 2013 at 10:02 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
Hi,
boost::synchronized_value (not released yet [1][2][3]) is based on [4]. See below part of this paper adapted to the Boost.Thread interface.
Currently boost::synchronized_value is in addition Copyable and Swappable. I was wondering if it is worth adding value and move semantics to synchronized_value. Making it EqualityComparable, LessThanComparable and Movable if the underlying type satisfy these requirements will allow to store them on a Boost.Container/C++11 container.
Do you see something completely wrong with this addition? Has some of you had a need for this? Could you share the context?
Sorry, I missed this discussion somehow. I've taken a quick look at the interface and have a few questions:
1. Why are there strict_lock_ptr and unique_lock_ptr? What are the differences and why we can't have one such ptr (presumably, unique_lock_ptr)? 2. I find value() and get() a bit confusing, since it is not apparent what is the difference between them. Maybe value() could be renamed to get_ref() or unsafe_get()? 3. Am I correct that having strict_lock_ptr/unique_lock_ptr acquired by calling synchronize() will not deadlock with operator-> when a non-recursive mutex is used?
Also, if it's not too late yet:
4. Could synchronized_value be renamed to just synchronized? Besides being shorter, this naming seems to be aligned with optional and reads more naturally. Consider:
optional< int > oi; synchronized< queue< int > > sqi;
...and also atomic: atomic< int > ai;