What were the reasons for excluding upgrade locks from the N3568 proposal

Question

I've done a bit of googling on this and have managed to find only scant information. N3568 included specification for an upgrade lock concept but the upgrade parts were then rejected during the standardisation process and a revised proposal was accepted (N3569) that excluded them but included the other parts.

Currently there exists in boost::thread an implementation for upgrade locks and they're tempting to use. But I'm curious as to the specific reasons that the concept was rejected by the standardisation committee before using that.

Questions:

• Why were upgrade locks excluded from N3568 rejected?
• What are the dangers of using the boost::thread implementation of upgrade locks, any known issues?
• Are upgrade locks ever going to appear in the standard or are they considered critically flawed?

Answer 1

• Why were upgrade locks excluded from N3568 rejected?

The concurrency group did not feel it was practical to identify a single upgrade thread for upgrade_mutex.

The concurrency group felt the upgrade facility would make the mutex more expensive (it did not in the reference implementation).

There was no interest in putting upgrade_mutex in C++14 (in the concurrency subgroup).

(these are quotes from the meeting minutes)

• What are the dangers of using the boost::thread implementation of upgrade locks, any known issues?

If BOOST_THREAD_PROVIDES_DEPRECATED_FEATURES_SINCE_V3_0_0 is defined, shared_mutex provides upgrade functionality. This is a bad idea. It is very important that shared_mutex and upgrade_mutex have distinct types for type-safety reasons. One needs to enforce at compile-time which mutex has upgrade capability, because its upgrade-locked state is exclusive among other threads vying for upgrade-locked.

I have not studied the boost upgrade_mutex enough to know how it deviates from N3568, so am unable to comment on it.

• Are upgrade locks ever going to appear in the standard or are they considered critically flawed?

I don't consider them critically flawed. However their practical use cases are rarer than shared_mutex, whose practical use cases are rarer than mutex. So they aren't needed by a large audience. But when you need one, it is very handy.

They will never become standard unless someone (more likely a sizable group of someones) chooses to invest the time and money to make it so. That someone will not be me, unless I am backed by a sizable group of people that want it badly enough to show up at standards meetings and vote in favor of it. I don't expect for that to happen since the use cases are sufficiently rare.

It is unfortunate that programmers aren't able to implement this completely on their own since it would involve intrusive changes to unique_lock and shared_lock (conversions among the three lock types). "Not implementable by a programmer" is one of the motivating reasons for putting something in the std::lib. But "not sufficiently widely needed" is also a reason for keeping things out of the std::lib. It is this last point that will require a grass roots movement to disprove, otherwise it is de facto true.