Обработка исключений под 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 - следует задать вопрос, в какой степени обсуждаемые там вопросы действительно и объективно релевантны для программирования, а в какой отражают лишь малоудачные стороны дизайна широко используемо языка С++ и помимо этого ценности не имеют.