Семафор не очень подходит, если нужно пробудить все ждущие потоки (логика manual reset event), а mutex+cond лично мне кажется избыточным, когда нужен флаг-событие. В WinAPI, к примеру, нет такого синхронизационного объекта как condition variable, эта абстракция реализуется на этой платформе с использованием event-а или семафора.
Подскажите, почему Вы не рассматриваете event как отдельный примитив синхронизации OS?
Известные мне реализации condition не умеют работать сами по себе без мьютекса, а вот event вполне себе может.
wiki
Без блокировок (англ. lock-free)
Для алгоритмов без блокировок гарантируется системный прогресс по крайней мере одного потока. Например, поток, выполняющий операцию «сравнение с обменом» в цикле, теоретически может выполняться бесконечно, но каждая его итерация означает, что какой-то другой поток совершил прогресс, то есть система в целом совершает прогресс.
Если код разросся до такого состояния, что существует куча логики с использованием блокировок в непонятных ситуациях, тогда lock-free алгоритмы точно не помогут такому коду, т.к. эти алгоритмы в разы сложнее алгоритмов с блокировками.
Я бы рекомендовал придерживаться нескольких правил, чтобы избежать взаимных блокировок:
1) мьютекс должен блокировать доступ к данным, а не код (если это возможно)
2) никогда не вызывайте внешний код из под блокировки (коллбеки и т.п.)
3) в идеале lock/unlock должны происходить в одной функции (RAII)
Проблемму фрагментации памяти в Windows решает технология Low-Fragmentation Heap, которая включена по умолчанию начиная с Vista, а в XP включается через WinAPI
Пример с надписью «Last Updated» это не плацебо, а правдивая информация.
Автоматическое обновление скрыто от глаз и не понятно как оно работает, и работает ли вообще, по этому дополнительная информация о времени последнего обновления привносит ясность.
В свое время меня так достала политика МТС, что я достал симку с телефона и разломал ее на четыре части, не взирая на то, что это был основной номер на протяжении шести лет.
>>rebase'ни его относительно master'а, squash'ни свои коммиты и попинай меня снова
Потому, что 'rebase' нужно делать через merge:
Делаем merge c веткой мастер, при этом происходит правильное слияние с учетом истории, также всегда создается новый коммит, по этому для того, чтобы откатить результат, достаточно перенести указатель ветки на один шаг назад.
После слияния ветка master будет являться началом Ваших изменений, rebase на master уже пройдет без конфликтов, можно делать squash, если того требует мэйнтейнер: rebase --interactive, либо вообще способ для ленивых reset --mixed и делаем новый коммит.
Важно: Если Вы знаете, что Ваши действия приведут к удалению оригинального коммита (как при rebase или reset) или если в чем-то не уверенны, сделайте резервный указатель (новый branch), к которому потом всегда можно будет вернуться.
Похоже на рефакторинг замена метода объектом методов, но только с какой-то кривой реализацией на статических переменных.
Данный рефакторинг имеет смысл, если у вас есть длинный метод, в котором локальные переменные так сильно переплетены, что это делает невозможным применение извлечения метода, то есть когда все настолько запущено, что другого выхода практически нет.
А если удалить только защитный слой, а амальгаму оставить, фоторамка не будет просвечиваться?
Кстати, недавно встречал видео рекламу на зеркалах в туалете (в Dream Town, Киев), удивило.
А чем Вас не устраивала «стандартного размера клавиатура», та, которая без надписей?
Мне на последней своей клавиатуре пришлось специально сдирать надписи лезвием…
Известные мне реализации condition не умеют работать сами по себе без мьютекса, а вот event вполне себе может.
Без блокировок (англ. lock-free)
Для алгоритмов без блокировок гарантируется системный прогресс по крайней мере одного потока. Например, поток, выполняющий операцию «сравнение с обменом» в цикле, теоретически может выполняться бесконечно, но каждая его итерация означает, что какой-то другой поток совершил прогресс, то есть система в целом совершает прогресс.
Я бы рекомендовал придерживаться нескольких правил, чтобы избежать взаимных блокировок:
1) мьютекс должен блокировать доступ к данным, а не код (если это возможно)
2) никогда не вызывайте внешний код из под блокировки (коллбеки и т.п.)
3) в идеале lock/unlock должны происходить в одной функции (RAII)
Советую попробовать Everything Search Engine, пользуюсь уже около 3 лет, мгновенный поиск любого файла. geektimes.ru/post/42354
Автоматическое обновление скрыто от глаз и не понятно как оно работает, и работает ли вообще, по этому дополнительная информация о времени последнего обновления привносит ясность.
Потому, что 'rebase' нужно делать через merge:
Делаем merge c веткой мастер, при этом происходит правильное слияние с учетом истории, также всегда создается новый коммит, по этому для того, чтобы откатить результат, достаточно перенести указатель ветки на один шаг назад.
После слияния ветка master будет являться началом Ваших изменений, rebase на master уже пройдет без конфликтов, можно делать squash, если того требует мэйнтейнер: rebase --interactive, либо вообще способ для ленивых reset --mixed и делаем новый коммит.
Важно: Если Вы знаете, что Ваши действия приведут к удалению оригинального коммита (как при rebase или reset) или если в чем-то не уверенны, сделайте резервный указатель (новый branch), к которому потом всегда можно будет вернуться.
Данный рефакторинг имеет смысл, если у вас есть длинный метод, в котором локальные переменные так сильно переплетены, что это делает невозможным применение извлечения метода, то есть когда все настолько запущено, что другого выхода практически нет.
Кстати, недавно встречал видео рекламу на зеркалах в туалете (в Dream Town, Киев), удивило.
до переименования:
после переименования:
Мне на последней своей клавиатуре пришлось специально сдирать надписи лезвием…