[thread] deprecating Mutex::scoped_lock and Mutex::scoped_try_lock and boost::condition
Hi, I would like to deprecate the following features in Boost.Thread: * Mutex::scoped_lock and Mutex::scoped_try_lock so that we can make mutex types independent from locks. The user should use instead unique_lock<Mutex> and the new public class try_unique_lock. * condition: This was there for forward compatibility since 1.35. The user should use instead condition_variable_any. What do you think? Best, Vicente
On Saturday 20 October 2012 13:08:18 Vicente J. Botet Escriba wrote:
Hi,
I would like to deprecate the following features in Boost.Thread:
* Mutex::scoped_lock and Mutex::scoped_try_lock so that we can make mutex types independent from locks. The user should use instead unique_lock<Mutex> and the new public class try_unique_lock.
Is try_unique_lock a new lock type? How is it different from unique_lock with try_to_lock argument?
* condition: This was there for forward compatibility since 1.35. The user should use instead condition_variable_any.
What do you think?
I'm ok with it.
Le 20/10/12 13:13, Andrey Semashev a écrit :
Hi,
I would like to deprecate the following features in Boost.Thread:
* Mutex::scoped_lock and Mutex::scoped_try_lock so that we can make mutex types independent from locks. The user should use instead unique_lock<Mutex> and the new public class try_unique_lock. Is try_unique_lock a new lock type? How is it different from unique_lock with
On Saturday 20 October 2012 13:08:18 Vicente J. Botet Escriba wrote: try_to_lock argument?
Mutex::scoped_try_lock is a legacy type that was defined as a typedef of an internal type for backward compatibility with version 1. namespace detail { template <typename Mutex> class try_lock_wrapper; } I'm proposing to rename this internal type as template <typename Mutex> class try_unique_lock; The single difference is that the constructor will try to lock instead of lock the mutex. If nobody needs it I just deprecate Mutex::scoped_try_lock and signal in the doc that the user can use a unique_lock using the try_lock_t tag. Best, Vicente
On Saturday 20 October 2012 17:27:40 Vicente J. Botet Escriba wrote:
Le 20/10/12 13:13, Andrey Semashev a écrit :
Is try_unique_lock a new lock type? How is it different from unique_lock with try_to_lock argument?
The single difference is that the constructor will try to lock instead of lock the mutex. If nobody needs it I just deprecate Mutex::scoped_try_lock and signal in the doc that the user can use a unique_lock using the try_lock_t tag.
IMHO, there is no need for this separate lock type, the same can be achieved with unique_lock.
Le 20/10/12 17:35, Andrey Semashev a écrit :
On Saturday 20 October 2012 17:27:40 Vicente J. Botet Escriba wrote:
Le 20/10/12 13:13, Andrey Semashev a écrit :
Is try_unique_lock a new lock type? How is it different from unique_lock with try_to_lock argument? The single difference is that the constructor will try to lock instead of lock the mutex. If nobody needs it I just deprecate Mutex::scoped_try_lock and signal in the doc that the user can use a unique_lock using the try_lock_t tag. IMHO, there is no need for this separate lock type, the same can be achieved with unique_lock.
Thanks for you quick answers. Vicente
Le 20/10/12 17:48, Vicente J. Botet Escriba a écrit :
Le 20/10/12 17:35, Andrey Semashev a écrit :
On Saturday 20 October 2012 17:27:40 Vicente J. Botet Escriba wrote:
Le 20/10/12 13:13, Andrey Semashev a écrit :
Is try_unique_lock a new lock type? How is it different from unique_lock with try_to_lock argument? The single difference is that the constructor will try to lock instead of lock the mutex. If nobody needs it I just deprecate Mutex::scoped_try_lock and signal in the doc that the user can use a unique_lock using the try_lock_t tag. IMHO, there is no need for this separate lock type, the same can be achieved with unique_lock.
Thanks for you quick answers.
I have created a ticket to track this. https://svn.boost.org/trac/boost/ticket/7537 Best, Vicente
On Sat, Oct 20, 2012 at 1:08 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
I would like to deprecate the following features in Boost.Thread:
Since when are the replacement functions available? Is deprecation a docs-only thing?
The user should use instead unique_lock<Mutex> and the new public class try_unique_lock.
Isn't the C++11 name lock_guard<mutex>? -- Olaf
Le 20/10/12 14:07, Olaf van der Spek a écrit :
On Sat, Oct 20, 2012 at 1:08 PM, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> wrote:
I would like to deprecate the following features in Boost.Thread: Since when are the replacement functions available? Since 1.35. Is deprecation a docs-only thing? I use to add a compiler flag that allows to disable/enable the inclusion of deprecated feature so that the users can in the transition path either disable the inclusion of the deprecated feature when it is there by default (3 releases) or enable it when it would not be the default (3 more releases) .
The user should use instead unique_lock<Mutex> and the new public class try_unique_lock. Isn't the C++11 name lock_guard<mutex>?
C++11 defines both. The current implementation uses unique_lock<mutex>. Besy, Vicente
On Oct 20, 2012, at 7:08 AM, "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr> wrote:
I would like to deprecate the following features in Boost.Thread:
How long do you propose to keep the deprecated interfaces before removing them? Will you provide a manifest constant to remove them so users can vet their code before the interfaces are removed permanently?
* Mutex::scoped_lock and Mutex::scoped_try_lock so that we can make mutex types independent from locks. The user should use instead unique_lock<Mutex> and the new public class try_unique_lock.
I have no problem, in principle, but be sure the names are consistent with C++11 or any related proposals, if applicable.
* condition: This was there for forward compatibility since 1.35. The user should use instead condition_variable_any.
+1 ___ Rob
On Oct 20, 2012, at 7:08 AM, "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr> wrote:
I would like to deprecate the following features in Boost.Thread: How long do you propose to keep the deprecated interfaces before removing them?
Will you provide a manifest constant to remove them so users can vet their code before the interfaces are removed permanently? I use to add a compiler flag that allows to disable/enable the inclusion of deprecated feature so that the users can in the transition path either disable the inclusion of the deprecated feature when it is there by default (3 releases) or enable it when it would not be the default (3 more releases) . All these will be of course documented.
* Mutex::scoped_lock and Mutex::scoped_try_lock so that we can make mutex types independent from locks. The user should use instead unique_lock<Mutex> and the new public class try_unique_lock. I have no problem, in principle, but be sure the names are consistent with C++11 or any related proposals, if applicable. As said in the preceding post, I'm not for maintaing this
Le 20/10/12 14:42, Rob Stewart a écrit : try_unique_lock so if no body is against I could just deprecate it. Best, Vicente
participants (4)
-
Andrey Semashev -
Olaf van der Spek -
Rob Stewart -
Vicente J. Botet Escriba