забавную штучку я раскопал, а потом и нашел по ссылке аналогичные наблюдения

http://groups.google.com/group/lock-free/browse_thread/thread/d7ac22f807d1d439


Возможно и похоже (я не проверял, у меня сейчас на виндах нет ни дебаггера ни даже С++, а дискуссия по ссылке чуток неадеквата), что сейчас под виндоуз невозможно написать 100% надёжный lock-free код, возвращающий память системе с помощью вызова free и подобного, а не возвращающий выделенную память в пул, либо использующий сборщик мусора.

Причина несколько тонка - в результате освобождения памяти может произойти исключение при доступе по "старому" указателю. Само по себе это не беда - можно надеяться словить исключение и обработать его как факт того, что указатель устарел.

Проблема, однако, в том, что адресуясь по устаревшим указателям наугад можно нечаянно задеть guard-page другого треда, а это, как это не смешно, приводит через непродолжительное время к терминации процесса.

Т.е. я опять ж не проверял, но не исключено, что функция InterlockedPopEntrySList имеет неустранимый, в рамках старого ядра виндов, баг.

Вообще, чего б этому самому ядру не заботиться о том, чтобы не сносить аттрибут guard-pages если они не относятся к стеку текущего треда? Ведь уже так или иначе исключение по доступу к guard page стека делается в kernel-mode, так отчего бы и нет? Впрочем, тогда либо придется вводить дополнительный аттрибут памяти "stack guard page", либо тупо проверять, а не относится ли данный guard-page на который нечаянно наступили, к какому-нибудь еще стеку, что действительно довольно тупо. Опять же, если продвинутый пользователь желает использовать guard-pages сам для своих собственных структур данных (а не для стека треда), то чужой тред снова имеет чудесную возможность долбануть по этому guard-page, получить исключение и поднять лапки кверху, поскольку что делать с этим исключением он не знает.

В общем, весь концепт guard-page задизайнен, похож, немного криво.
----------------------------------
С другой стороны, как отмечают тут (ссылка аж с 2003-го года!) память может быть замаплена и на порты ввода-вывода устройств, и тут уже остается не жаловаться на кривой дизайн или имлементацию guard-page, а просто, видимо, обозначить, что lock-free синхронизацию принципиально нельзя делать без поддержки сборщика мусора (которому самому желательно быть lock-free :-))) или рецайлинга объектов (даже не памяти, а именно объектов, чтобы будущие адресации нечаянно не попали на переалллоцированный объект другого формата).

Вроде, подобные мысли время от времени попадались, но не так чтобы где-то я видел их четко и однозначно сформулированными. Надо будет что-нидь перечитать по теме.
--------------------
UPD: перечитал. был неправ. можно память и освобождать. без сборщика мусора. и без рецайклинга. но аккуратно. )))

В это тяжело поверить, но какой-то программер умудрился написать код, который может прочитать значение приватного члена произвольного класса.

В рамках стандарта. :-)

А почему б не считать класс параметризованный приватным классом - опять же приватным...
а не ломать компиляцию почем зря.

Товарищ Андрей Александреску, известный мне не только как гениальный С++ программист и извращенец в хорошем смысле этого слова, но и как автор довольно позорных статей и утверждений в области мультитреда (видно, сказалось головокружение от успехов), оказывается, еще в старом 2004-м году рекламировал на страницах DDJ идеи lock-free программирования, вполне подробно и внятно описывая его преимущества:

http://www.drdobbs.com/cpp/184401865

и даже написал продожение к этой статье "в соавторстве" с Магедом Майклом, звездой мирового уровня в этом самом lock-free.

http://www.drdobbs.com/184401890 (еще не прочитал)

Я последние пару месяцев потихоньку в этой области пытаюсь что-то почитывать - неплохая зарядка для мозгов. И вообще... доставляет.

до сих пор не осознавал четко, что время в каждом процессоре бежит по-своему и что никакого опреденного порядка доступа к памяти нет, а есть только видимость с точки зрения каждого процессора.

Ну, скажем, в Intel x86 можно считать, что на каждой команде записи в память стоит release-барьер, а на каждой команде чтения из памяти стоит acquire-барьер, а на каждой lock-инструкции стоит двусторонний барьер, но вот что означает слово "total" в предложении "locked instructions have a total order", и почему об этом вообще надо отдельно говорить, до меня как-то не доходило.

Вот, скажем, и по этой ссылке http://www.bluebytesoftware.com/blog/2008/07/17/LoadsCannotPassOtherLoadsIsAMyth.aspx далеко не последний человек в Микрософте и автор толстенной книжки по мультитреду выглядит смущенным фактом того, что не существует самого по себе "общего порядка", "total order" исполнения операций процессорами. Тот факт, что два процессора могут быть несогласны относительно того, кто из них раньше, а кто позже выполнил свою операцию записи в память он трактует как то, что операции чтения из памяти могут переупорядочиваться (мол, вопреки обещаниям компинии Intel и вопреки спекам процессора). Меж тем, никакого абсолютного "раньше и позже" тут нет, поскольку речь идет о чтении данных, записанных двумя разными процессорами. И в этом всё дело.

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

Это куда как проще оказывается. :-)))

У меня, скажем, как-то валялась статья, в которой я года 3 не мог разобраться. Ну не простой там был код, не простой. Пока, наконец, за одно утро, сидя в очереди к врачу, я не понял, что код - просто туфта. Т.е. показатель эффективности (отношение времени потраченного на разбор кода ко времени потраченному на его разгром) - несколько сотен. И если б это было единожды...

А не забавно ли, мягко говоря, что начинающий программист на Win32 мало того, что не способен написать thread-safe синглетон, но и, в сущности, вряд ли сможет понять мало-мальски эффективное решение, не прослушав перед этим получасовую, как минимум, лекцию?

http://community.livejournal.com/ru_cpp/366267.html

Что важно, ситуация такая имеется только под Win32, поскольку на юниксовых pthreads есть статичиски-инцициализируемые критические секции, не говоря уже о давно существующем pthread_once, и программист может просто тупо пользоваться этими вещами и не забивать себе голову всякой платформенной эзотерикой.


Кстати 1: на Висте вещи вроде pthread_once тоже есть.
Кстати 2: fast_pthread_once

В который раз немножко поговорили про тонкости мультитрединга на С и виндах.

http://community.livejournal.com/ru_cpp/347512.html

Пора бы как-то разобраться с ООП и закрыть эту тему для себя. По возможности, окончательно. Предварительные выводы, скорее уж проектируемые направления работы:

1. Типы (интерфейсы, наследование классов от интерфейсов, правила переопределения функций в производных классах) есть более или менее удачная попытка реализовать строгую типизацию языков ООП. Неудачная типизация ограничивает возможности языка и ограничивает мышление программиста, воспитанного на основе её изучения. Чтобы разобраться в ООП, типизацию необходимо послать подальше.

2. Наследование (классов от других классов) есть некоторый (со своими возможными граблями) паттерн повторного использования кода, поддерживаемый языком. Вообще, ввод понятия класса есть опять же некий паттерн реализации минимальных функциональных элементов в ООП. Чтобы разобраться в ООП, идею наследования и классов желательно подвинуть в сторону.

3. ООП не универсально. Не всё ложится в его схему, и не должно ложиться. Даже моделирование объектов внешнего мира может не уложиться в конкретную ООП-схему. Может ли уложиться хоть в какую-то -- вопрос открытый. Им стоит заняться.

4. Правильное построение механизма наследования и типизации есть крайне нетривиальная задача. Только после проработки первых трёх пунктов имеет смысл ей как-то заняться.

the term spaghetti stack is closely associated with implementations of programming languages that support continuations. Spaghetti stacks are used to implement the actual run-time stack containing variable bindings and other environmental features. When continuations must be supported, a function's local variables cannot be destroyed when that function returns: a saved continuation may later re-enter into that function, and will expect not only the variables there to be intact, but it will also expect the entire stack to be there, so it can return again! To resolve this problem, stack frames can be dynamically allocated in a spaghetti stack structure, and simply left behind to be garbage collected when no continuations refer to them any longer. This type of structure also solves both the upward and downward funarg problems, so first-class lexical closures are readily implemented in that substrate also.

via wikipedia