https://twitter.com/CompileExplore/status/1431022441917210625
Я единственный слоупок который не знал об этой фиче?
В общем это прям классно, единственный минус, нельзя ничего качать в cmake :(
Есть issue, но там пишут что по secure причинам не хотят разрешать.
Есть мысль что можно предложить local storage из которого будут пытаться по alias-у забрать
Но в целом это не супер важно, пример работы фичи с яклибом:
https://godbolt.org/z/e6WP4Wb6o
// Как вы блокируете > 1 мьютекса?
Наверно у вас есть на них какой-то порядок, либо вы используете
std::lock (иначе possible deadlock).std::lock использует алгоритм наподобии (только обобщенный до n мьютексов):while (true) {
std::unique_lock l0(m0);
if (m1.try_lock()) {
l0.release();
break;
}
l0.unlock();
std::this_thread::yield();
std::unique_lock l1(m1);
if (m0.try_lock()) {
l1.release();
break;
}
l1.unlock();
std::this_thread::yield();
}
И мне всегда казалось неочевидным, что это лучше, чем упорядочить по адресам (адрес обьекта мьютекса не может измениться, что кстати должно быть неправдой в rust?).Недавно в коде folly обнаружил ссылку на любопытную статью с бенчмарками
http://howardhinnant.github.io/dining_philosophers.html
В общем если у вас не естественный порядок (например у вас всего два мьютекса и вы всегда держите блокировку на первом дольше чем на втором)
std::lock покажет себя лучше чем упорядочивание по адресам.Условный пример, когда
std::lock лучше:У вас есть счета юзеров, каждый из них обладает мьютексом.
Чтобы совершить перевод с одного счета на другой вы блокируете мьютекс отправителя и мьютекс получателя
