Sergey Zubkov

> int a[] = {1,2,3,9,-1,-2,-3} in that case the take_while is just a view into the original range, in this case, finite range with 7 elements in it > I...

Could this incorporate or list separately my old bit from the TODO chapter of the guidelines, "atomic bool whose value is set outside of the mutex is wrong". It seems...

yet another question on SO asking what's wrong with using unprotected atomic bool as a condition http://stackoverflow.com/questions/38147825

The main part of this issue appears to be have been written as [CP.42: Don't wait without a condition](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#cp42-dont-wait-without-a-condition) back in april https://github.com/isocpp/CppCoreGuidelines/commit/e8dea3807a6f01254612a39be94df659137d558e although the part about always using a...

...and another StackOverflow sighting of the mutex use [Why do I need to acquire a lock to modify a shared “atomic” variable before notifying condition_variable](http://stackoverflow.com/questions/41867228)

> Is there any special reason why the c++ standard library didn't get a semaphore class? Not one of the experts you're looking for, but boost.thread FAQ from 2003 had...

Another Stackoverflow sighting of updating the condition without holding the mutex: [Possible race condition in std::condition_variable?](http://stackoverflow.com/questions/42470773)

Could just weasel-word it out as "thread2 could miss the notification" thread2 is also buggy in that it does work on every spurious wakeup (which aren't theoretical: changing system time...

A counterexample is ClonableBase from [C.21: If you define or =delete any copy, move, or destructor function, define or =delete them all](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rc-five) but I think there could be a useful...

this will likely be addressed after #1606 is discussed/merged (which is waiting on the results of an offline discussion)