default mutex type in std::lock_guard and Co

46 views
Skip to first unread message

Viacheslav Usov

unread,
Aug 17, 2016, 11:46:43 AM8/17/16
to std-dis...@isocpp.org
Is there a reason why std::lock_guard and std::unique_lock must always be explicitly decorated with a mutex type?

Why is std::mutex not a reasonable default for that?

Cheers,
V.

Anthony Williams

unread,
Aug 17, 2016, 12:13:27 PM8/17/16
to std-dis...@isocpp.org
With C++17 class template deduction it is not needed as it will be deduced:

std::lock_guard guard(my_mutex); // look no template parameters

Anthony
--
Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/
just::thread C++11 thread library http://www.stdthread.co.uk
Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

Viacheslav Usov

unread,
Aug 17, 2016, 12:24:52 PM8/17/16
to std-dis...@isocpp.org
On Wed, Aug 17, 2016 at 6:13 PM, Anthony Williams <antho...@gmail.com> wrote:

> With C++17 class template deduction it is not needed as it will be deduced:

Thanks, I keep forgetting all the goodies we are promised to have eventually :)

Anyway, out of my curiosity, was there a good reason before C++17 not to have a default for those types?

Cheers,
V.

Richard Hodges

unread,
Aug 17, 2016, 12:37:41 PM8/17/16
to std-dis...@isocpp.org
In any class that I write that involves mutexes and locks, I almost always end up with this:

class Foo
{
  using mutex_type = std::mutex;
  using lock_type = std::unique_lock<mutex_type>;

private:
  lock_type get_lock() const { return lock_type(_mutex); }

  mutable mutex_type _mutex;
};

Since I have written this same boilerplate code about 50 times, it makes me think that automatic deduction of a mutex's lock type is absolutely essential. 


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-discussion+unsubscribe@isocpp.org.
To post to this group, send email to std-dis...@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-discussion/.

Thiago Macieira

unread,
Aug 17, 2016, 5:41:47 PM8/17/16
to std-dis...@isocpp.org
On quarta-feira, 17 de agosto de 2016 18:24:49 PDT Viacheslav Usov wrote:
> On Wed, Aug 17, 2016 at 6:13 PM, Anthony Williams <antho...@gmail.com>
>
> wrote:
> > With C++17 class template deduction it is not needed as it will be
>
> deduced:
>
> Thanks, I keep forgetting all the goodies we are promised to have
> eventually :)
>
> Anyway, out of my curiosity, *was* there a good reason before C++17 not to
> have a default for those types?

So that lock_guard can be used with other mutex types besides std::mutex.
Having a default would have allowed you to use std::lock_guard<>, but you
still need the <>.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center

Viacheslav Usov

unread,
Aug 18, 2016, 4:46:07 AM8/18/16
to std-dis...@isocpp.org
On Wed, Aug 17, 2016 at 11:41 PM, Thiago Macieira <thi...@macieira.org> wrote:

> So that lock_guard can be used with other mutex types besides std::mutex.

That's a strange answer. A default for the type would not prevent that.

> Having a default would have allowed you to use std::lock_guard<>, but you still need the <>.

Sure. I just thought there must have been some profound reason why the template parameter type had no default. std::mutex as a default seems quite reasonable to me, but obviously not to the committee, so I hoped I could learn something new.

Any more insight?

Cheers,
V.

Klaim - Joël Lamotte

unread,
Aug 18, 2016, 5:34:32 PM8/18/16
to std-dis...@isocpp.org
I guess that no, it's more a general issue with types that take template arguments which could be deduced via a constructor argument.
Like: sd::unique_ptr<Foo> foo{ new Foo }; have the same problem.
Helper functions like make_unique does the trick but it was pointed that it would force all template types to have make_* functions to help
with automatically construct the type.
(Note that you could generalize your example by making a free function instead of a member function, and use that instead, if your compiler works correctly)

There was no reason FOR this restriction (if my memory is correct), it's more like it was not allowed in doubt in the past and only recently did a proposal
provide a good enough solution at a good enough time so that it is generally fixed (as pointed before by Anthony Williams).

Anthony Williams

unread,
Aug 19, 2016, 1:03:29 PM8/19/16
to std-dis...@isocpp.org
On 17/08/16 17:24, Viacheslav Usov wrote:
> On Wed, Aug 17, 2016 at 6:13 PM, Anthony Williams <antho...@gmail.com
> <mailto:antho...@gmail.com>> wrote:
> Anyway, out of my curiosity, /was/ there a good reason before C++17 not
> to have a default for those types?

Firstly, I don't think it was in any of the papers. If things aren't in
a proposal paper then they don't happen, however good an idea people
think they are. This is probably the main reason: none of the people who
liked the idea cared enough to write a paper for it, or convince one of
the people who were writing the mutex papers to add this.

Secondly, IIRC, at least one person thought it was good to spell it out,
to clarify which mutex type is being used. Others said they would always
use a typedef anyway, so it didn't save much.

HTH,
Reply all
Reply to author
Forward
0 new messages