В интернете кто-то снова не прав!

Точнее, в оплоте создателей стартапов и специалистов по натягиванию шаблонов на wordpress - хабрахабре :)

Некий юзер, взялся переводить статьи о lock-free алгоритмах на великий и могучий, за что ему спасибо конечно. Но к несчастью для себя, он покусился на святое! По своему перевел термин lock-free на русский язык! Идея, на мой взгляд, крайне неудачная, особенно в свете того, что уже давно прижился перевод - "без блокировок".

Почему lock-free неправильно переводить как "беззамочный"? Все очень просто, в информатике нет "замков", зато есть блокировки. Здесь даже говорить не о чем.

Немного сложнее с "беззахватными" алгоритмами. Под захватом подразумевается захват некоего ресурса, например мьютекса, то есть определенную семантику. Lock-free алгоритм, конечно же не может ничего захватывать.

Гарантия lock-freredom означает, что в каждый момент времени, один из потоков совершает прогресс. Полезным на практике следствием соблюдения lock-freredom гарантии является то, что мы можем прибить любой из потоков, выполняющих наш lock-free алгоритм и у нас гарантированно не возникнет dead-lock. Если гарантия lock-freedom не соблюдается, то один из потоков может сделать нечто такое, что заставит другие потоки его ждать. Например, захватить мьютекс. Если мы этот поток прибьем, то возникнет dead-lock.

Так вот, гарантия lock-freedom может не соблюдаться даже при полном отсутствии мьютексов, критических секций и любых других объектов, имеющих такую семантику. Например, приложение может не использовать общие для нескольких потоков данные вообще, посылая, вместо этого сообщения. При этом, взаимная блокировка возникнуть очень даже может. Поток, по каким-то причинам(например, из-за того, что его убили), может не посылать сообщение другому потоку, который это сообщение ждет.

Поэтому, я считаю термин "беззахватный" крайне неудачным, не отражающим сути.

P.S.

Я несколько раз написал о том, что поток может быть "прибит". В Windows это может быть сделано функцией TerminateThread, например. Так вот, прибивать потоки, не в коем случае не нужно. Это может привести к непредсказуемым последствиям. Если вы используете эту функцию, то у меня для вас плохие новости!

За все время работы, мне лишь однажды пришлось столкнуться с этой проблемой. Я написал библиотеку, клиент которой часто вызывал TerminateThread. Это иногда приводило к неприятным последствиям. Поэтому, мне пришлось предоставить этому клиенту lock-free интерфейс.