yigal_s

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

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

У меня, скажем, как-то валялась статья, в которой я года 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

ой, какой раритет появился:
Пильщиков. "Язык Плэнер" (советская серия "библиотечка программиста")
[link]
да еще скан экземпляра за подписью автора.

Сейчас медитирую перед четырьмя небезынтересными и там-сям рекомендованными книшками:

Хендерсон П. - Функциональное программирование, применение и реализация -- пока напечатал и прочитал несколько десятков страниц, вводит в тему на неплохой очень скорости, изложение строится вокруг Лиспа. Интересно. Но пока мало прочитал.

А.Филд, П.Харрисон - Функциональное программирование -- вводят свой, кажется, язык Hope, чисто функциональный с возможностью ленивых вычислений и строгой типизацией. В общем, тоже про реализацию в основном. Прочитал где-то четверть, введение в тематику. Слегка нудновато, порой не очень ясно, но в целом смысл очень наличествует.

John Harrison - Introduction to Functional Programming -- пока не открывал. Обсуждаемый язык - ML

Хювёнен, Сеппянен - Мир Лиспа. -- пол-первого тома мне показались фатально скучными. Потуги автора на оригинальность (какие-то иконки на полях книги) не вдохновили. Пожалуй, если бы не имел отрывочной информации по Common Lisp, то и не осилил бы. Второй том, впрочем, обещает быть очень насыщенным чем-то вполне нетривиальным. Кажется. Будет время - буду вычитывать дальше. Со стоном.

Вообще, с поправкой на слабое знакомство с темой, такое ощущение, что применение лично я ей вряд ли найду. Некая вещь в себе, спрос на рынке минимальный, и, очевидно, там где этот спрос есть, профессионалов хватит, а неучи, не разбирающиеся, скажем, в алгоритмах AI особо и не нужны. Надо бы еще, впрочем, Эрланг поглядеть. Он может оказаться чуток ближе к актуальной мне практике.

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

На знаменитом ныне sql.ru (где ксеноцефал) я недавно обнаружил упоминание работ Luca Cardelli из Microsoft Research.

На мой вкус, колоссальный чувак. ( Read more... )

Где ООП явно не в тему - это ГУИ (пример правильного построения гуя - Fudgets).

[link]

Я так-сяк повертел это заявление (и прочие, прочитанные на sql.ru), вспомнил некоторые почему-то не получившиеся для написания задачи из своей практики, равно как и некоторые "гениальные ООП решения", и сформулировал супер-радикальный тезис:

Объектно ориентированное программирование менее всего подходит для отображения объектов реального мира (включая сюда и объекты - элементы GUI) в объекты (в терминологии OOP/D) программы.

Пожалуй, истиннонсть этого тезиса мне пока трудно всерьез обосновать (ложность же напрашивается). Но что-то в этом есть. По крайней мере, стоит об этом тезисе вспоминать, прежде чем бросаться всё и вся выражать в виде объектов и протокола их взаимодействия, а потом тупо думать - что ж оно всё никак не выражается?

Почитать, что ли Симулу какую... Для избавления от ереси неверия в то, во что верил последние 14 лет.

Я даже не знаю, как это отрекламировать.

Короче, если Вы не гениальный программист, возможно, Вам стоит это почитать

избиение младенцев

на 6-й странице из 66 я понял, что мертв профессионально. Собственно, это и раньше подозревалось, но не с такой ощутимой ясностью.

Продолжаю читать дальше. Весело. Конспектируя ссылочки.

via potan

xref

upd: прочитал всё полностью. жутко доволен

Обработка исключений под Windows - это что-то особенное.

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

В XP тут вообще конь не валялся - стоит выгрузить код обработчка, так в ответ на исключение по вызову оного, вся карусель по исполнению обработчиков (уже нового) исключения заверчивается заново. И снова. И снова. Результат - переполнение стека.

В Win 2003 тут понаворотили стра-ашных "защит" - перед вызовом обработчика, проверяют, присутствует ли его код. Или что-то вроде того, я не вдавался. Кажется, правда, что и на XP проверяют, но эта проверка почему-то ничего не ловит. Опять же не вдавался. Короче говоря, в 2003 переполнения стека в этом сценарии не будет. Не будет. В этом сценарии. Зато они умеют, прямо там, выяснив, что обработчик исключения уже выгружен, немедленно корректно закрешить аппликацию. Вызвав (из под ntdll.dll) UnhandledExceptionFilter и всё на него навешенное.

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

Функция IsBadReadPtr и прочие из той же группы очень давно мне не нравились. Ну хотя бы тем, что в данный момент такая функция может выдать тебе, что по данному адресу можно что-то читать, а уже через долю секунды другой тред как-нибудь перераспредилит память, и читать уже не получится. То есть, думал я, не лучше ли сразу читать проблемную память из под try-except блока, не заморачиваясь предварительными проверками?

Реальность, однако, оказалась куда как хуже. Даже в чем-то безнадежной она оказалась.

Выяснилось, что:

если доступ к памяти "наугад", будь он сделан через IsBadReadPtr или же простое чтение памяти из-под try-except блока, нечаянно попадет на guard-страницу стека чужого треда,

то guard-аттрибут этой страницы будет снесён,

что впоследствии, когда стек второго треда подрастет за пределы той бывшей guard-страницы, приведет к "исчерпанию" стека этого треда и катастрофическому и молчаливому завершению всей аппликации.

Конечно, при касании guard-страницы, кидается STATUS_GUARD_PAGE_VIOLATION исключение, и можно было бы попытаться восстановить аттрибут guard-страницы. Можно было бы, если бы не очевидный race-condition: пока мы будем восстанавливаеть аттрибут, второй тред уже может навернуться. Функция же IsBadReadPtr попросту ловит все исключения, и обрабатывает их единообразно, и не пытаясь восстанавливать какие-то там аттрибуты.

И если бы только это...

Выяснилось, что безотносительно вышеупомянутых бед, функция IsBadWritePtr еще и способна повреждать данные в мультитредной аппликации! А именно, чтобы проверить, можно ли записать данные, она их сначала читает, а потом уже пишет прочитанное значение по тому же самому адресу. Если между чтением и записью какой-то другой тред изменит значение данных, то это измененное значение будет немедленно затерто старым.

Всё это, кстати, уже документировано на сайте msdn.

1. Бытует мнение, что с exceptions программировать значительно сложнее, чем без них без них. Мол, exceptions привносят уйму новых проблем.
На самом деле, если абстрагироваться от мелких заморочек в С++, никаких новых проблем, не известных ранее, exceptions не привносят. По крайней мере, не привносят в то программирование, где не принято игнорировать возвращающиеся из вызова функций коды ошибок или выходить из функции по получении такого кода, не заботясь о консистентности данных.

2. 1991 год. Во втором издании книги "Язык программирование С++" Страуструпа, exceptions было посвящено всего 30 страниц. Всё выглядит просто и красиво.

3. Конец 1994 года. Я тогда прекрасно разбирался в exceptions. В тех самых тридцати страницах. В журнале "С++ Report" появляется статья "Exception handling: a false sence of security", автор которой признается, что, видимо, не способен написать exception-safe стек (!) Вслед за ним свою неспособность сделать это, видимо, должен признать и средний, а то и продвинутый программист С++ того времени.

( еще шесть пунктов )

1. Semaphores
2. Monitors (conditional variables).
3. Messages, рандеву, remote calls, actors (пока не разобрался, одно ли это и то же концептуально, или есть разница. Вообще, в принципе, больше "слышал звон", чем "в теме". Потихоньку разберусь)
4. transactional memory - несколько дней назад где-то ссылку на это дело подобрал.

Интересно, есть еще что-то неупомянутое?

-----
Upd: собственно, в списке представлена некоторая линия эволюции (хотя линейной эволюции в реальности, видимо, не было в точности) способов "синхронизации", вернее, написания мультитредного кода.

> Проблема с С++ - это сложность в понимании/написании/употреблении мультитрединговой модели с точки зрения организации правильного доступа к данным/синхронизации и т.п.

Чего я не могу понять - это почему POSIX Threads/C code не страдает теми же проблемами, а наоборот есть "наиболее удобное сочетание для написания сложных мульитрединговых програм с элементами real-time".

[ link ]

Я понял, я понял. С++ - это как бы жид в мире языков программирования.

Успешен (но не по праву успешен). Презираем. Критикуем за грехи, коих не совершал. Но оправдания не помогают - ибо с ним всё равно всё понятно.

Примерно так.

Сам avva тоже писал, что C++ плохой язык, а C хороший. И вот тут, хоть я и иначе ощущаю проблемы языка С++, по сути, а не по мелочам вряд ли можно возразить.

Хотя... вот интересно, если иметь всего две альтернативы: писать системы средней и большой сложности на С, или писать на С++ - выберет ли хоть кто-нибудь С? Ну да, выберет. Ведь уже сказано - "наиболее удобное сочетание для написания сложных мульитрединговых программ с элементами real-time".

* Вот тут очень убедительно утверждается и соблазнительно описывается, что для concurrent программирования правильно использовать не семафоры, даже не conditional variables, а передачу сообщений. Крайне заинтригован. В своё время мне не хватило времени и желания разобраться с распределёнными алгоритмами (попадались черезчур математизированные книги с неясными перспективами практического использования изученного), но, похоже, непременно надо будет вернуться к теме.

* Cтрауструп написал дополнительное (современное) предисловие к "Design and Evolution of C++" http://www.research.att.com/~bs/DnE2005.pdf Излагает прошедшую историю с момента написания книги, текущий статус, возможные перспективы на ближайшие десять лет. К С++ у меня сейчас очень сложное отношение, но факт остается фактом - от этого языка я пока никуда не ушел, а для проектов, которыми я занимался последние лет десять, он был вполне адекватен, по большей части.

* Когда познакомился с Object-oriented, очень быстро обнаружил, что мыслю уже не на уровне алгоритмов, функциональностей или модулей, а на уровне классов. Вообще, было бы интересно подыскать какие-то задачи, примеры, где объектно-ориентированный подход не просто не очень удачен или проблематичен, но и в принципе уводит от более эффективного и адекватного решения.

У avva здесь зашел разговор, какие языки программирования стоит учить.

Жаль, но мне об этом особо нечего сказать. Всё пожрал хомяк C++.

До него учил я и APL и Forth и (не очень успешно, как сейчас понимаю) Lisp и Planner. После него - ничего. Лишь чтение Мейреса, Александреску и Саттера, шлифовка деревянного клинка. Про partial template specialisations прочитал где-то около 97-го года наверное, долго страдал от отсутствия поддержки оных в используемых компиляторах, потом и думать забыл об этом. Тем временем, мимо пролетели как boost (вот уж в чем, жаль, не удалось поучаствовать), так и C++0x.

тривиальная проблема с приемом проф-интервью (у программистов):

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

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

Конечно, можно и нужно следить, как человек рассуждает в ходе даже и нерешенной задачи, но иметь некий набор не очень сложных, но показательных задач, которые человек был бы "обязан" решить, и это бы убедительно и достоверно свидетельствовало об его уровне, тоже очень бы хотелось.

Казалось бы, чудо произошло.

Начиная с Visual C++ 2005, внутри кода можно расставлять memory barriers, написав, к примеру, вызов intrinsic функции

_ReadWriteBarrier();

Мало того, в спецификацию volatile-типов добавлено долгожданное: операции над ними имеют семантику memory barriers.

И всё бы ничего, но ( Read more... )

По поводу серии книг Саттера и вообще всей этой бучи GOW - следует задать вопрос, в какой степени обсуждаемые там вопросы действительно и объективно релевантны для программирования, а в какой отражают лишь малоудачные стороны дизайна широко используемо языка С++ и помимо этого ценности не имеют.

Действительно, надо на время забросить расистский, шовинистический, антисемитский и всякий другой необщепринятый, хотя и небесполезный в нашем нетривиальном мире, дискурс, и попинать немножко ногами что-нидь из программирования. Пинать я буду не голословно, а приводя малоизвестные и интересные (очень надеюсь) примеры.

Самая мерзкая вещь, которую я только знаю в ООП - это так называемое "наследование". ( Не понимаю, как вообще можно его использовать, когда... ) Ясно совершенно, что действительное число - частный случай комплексного. Поэтому, если оформлять их в виде классов, то действительный тип должен наследовать комплексный. Именно так и не иначе. Комплексный тип - базовый. ( Read more... )Хотя квадрат и является разновидностью прямоугольника (не говоря уже о том, что и ромба тоже), поспешно было бы наследовать квадрат от прямоугольника. ( Read more... ) Проблема здесь в том, что прямоугольник в программировании и прямоугольник в математике вовсе не одно и то же. ( Read more... )

Всё же ужасно грустно, что в любимом моём С++ нет блока try-finally.

Как ни дёргайся, а пристойный exception-safe код написать никак не получается. И временами это просто уже бесит.

> I don't quite see how to add a timeout function using your algo. without
> getting race-conditions...

Интересный код.

Некий изысканный Windows NT программист вместо того, чтобы присвоить значение указателю вот так:

          pointer = new Object();

и проверить его в другом месте вот так:

          if(pointer)
          {
             pointer->Method();
             //etc...
          }

присвоил его с использованием Interlock-операции вот так: ( далее... )

.