Предшествующая статья про исключения в С++ оставила кучу тёмных мест,
главное, что осталось непонятным — так как же всё-таки осуществляется
передача управления при возбуждении исключения?
С SJLJ всё понятно, но, утверждается, что эта технология практически
вытеснена некоторым без-затратным (при отсутствии исключений) табличным механизмом.
А вот что это за механизм такой и как он устроен, будем разбираться под катом.

Фантастика как жанр заставляет читателей и писателей выйти за пределы разумного, дать волю своему воображению и отправиться в неизведанные миры. За это мы и любим этот жанр. RoboHunter этой осенью предлагает с головой погрузиться в мир научной фантастики.

Камень преткновения — GC

Все managed языки такие как Java или C# имеют один существенный недостаток — безусловное автоматическое управление паматью. Казалось бы, именно это и является преимуществом managed языков. Помните, как мы барахтались с dandling-указателями, не понимая, куда утекают драгоценные 10KB в час, заставляя рестартать наш любимый сервер раз в сутки? Конечно, Java и C# (и иже с ними) на первый взгляд разруливают ситуацию в 99% случаев.

Так-то оно так, только вот есть одна проблемка: как быть с большим кол-вом объектов, ведь в том же .Net никакой магии нет. CLR должен сканировать огромный set объектов и их взаимных ссылок. Это проблема частично решается путём введения поколений. Исходя из того, что большинство объектов живёт недолго, мы высвобождаем их быстрее и поэтому не надо каждый раз ходить по всем объектам хипа.

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

Однако на практике это сделать не удаётся. Как только мы добавляем первые 10 миллионов объектов и они “устаревают” из первого поколения во второе, то очередной полный GC-scan “завешивает” процесс на 8-12 секунд, причём эта пауза неизбежна, т.е. мы уже находимся в режиме background server GC и это только время “stop-the-world”. Это приводит к тому, что серверная апликуха просто “умирает” на 10 секунд. Более того, предсказать момент “клинической смерти” практически невозможно.
Что же делать? Не хранить много объектов долго?

Зачем

Но мне НУЖНО хранить очень много объектов долго в конкретной задаче. Вот например, я храню network из 200 миллионов улиц и их взаимосвязей. После загрузки из flat файла моё приложение должно просчитать коэффициенты вероятностей. Это занимает время. Поэтому я это делаю сразу по мере загрузки данных с диска в память. После этого мне нужно иметь object-graph, который уже прекалькулирован и готов “к труду и обороне”. Короче, мне нужно хранить резидентно около 48GB данных в течении нескольких недель при этом отвечаю на сотни запросов в секунду.

Вот другая задача. Кэширование социальных данных, которых скапливаются сотни миллионов за 2-3 недели, а обслуживать необходимо десятки тысяч read-запросов в секунду.

Похоже, я стал одним из первых русских обладателей трекера активности от Xiaomi [сяо ми] — Mi Band. Сегодня я сделаю анбоксинг браслета, расскажу о его функциях и личных впечатлениях. Он совместим с любым смартфоном на Android 4.3 и выше, и обладающим Bluetooth 4 LE.

Цена игрушки — 79 юаней, или приблизительно $15 USD. Девайс куплен в Китае с официального сайта производителя. Если вы еще не знаете, каких трудов стоит покупка, в конце обзора я дам ссылку. Я не занимаюсь продажей браслетов, не сотрудничаю с перекупщиками — вы и сами знаете, где можно заказать китайские девайсы.

Технические характеристики

Вот заявленные характеристики и возможности трекера и приложения для смартфона:

• Шагомер;
• Трекер сна;
• Умный будильник;
• Уведомление о поступающих звонках;
• Счётчик калорий;
• Работа в режиме ожидания до 30 дней;
• Разблокировка смартфона — для владельцев устройств с прошивкой MIUIv6 (и не только);
• Размер: 36х9х14 мм;
• Материал: пластик, алюминий;
• Влагозащита: IP67;
• Аккумулятор: 41mAh;
• Bluetooth-чипсет: Dialog BT4LE;
• А ещё некий «военный датчик»

Этот пост будет полезен всем, кто хотя бы иногда что-то готовит сам, а также помогает или мешает это делать другим.
Из него можно узнать, что это за гаджет — мультиварка, какие у нее технические возможности и невозможности, внутренность, наружность, достоинства (много) и недостатки (тоже много). Расскажу кое-что и о маленьких мультиварочных хитростях, а также позволю себе общее лирическое отступление о программировании на кухне.
Цель поста — рассказать про мультиварки, как класс объектов, не выделяя особо его представителей, но, чтобы не вести разговор о сферической мультиварке в вакууме, сделаю основным примером разбора мою модель — Panasonic SR-TMJ181.
Те, у кого нет мультиварки узнают, нужна ли она им, но и те, у кого она есть, надеюсь, без новых знаний не останутся.

Сразу же после появления на свет вышеуказанного фреймворка я понял — это именно то, чего так долго не хватало. Влезать в кабалу создания огромного количества классов используя фреймворки Cairngorm или PureMVC очень не хотелось, а с приходом Mate, появилась возможность уменьшить общую связанность компонентов приложения и использовать безболезненный обмен сообщениями(событиями) декларируя их в «родном» mxml.

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

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

Поделюсь теми, на которые подписан я:

Многие слышали о мифических словах — nVidia CUDA, AMD Brook, IBM/Sony Cell… Ходят слухи, что одно лишь упоминание оных заставляет вашу программу работать в сотни раз быстрее. Попробуем разобраться, что они из себя представляют, как выглядит это магическое высокопроизводительное программирование в общих чертах, и какой выигрыш они могут обеспечить в сравнении со старыми добрыми процессорорами x86.

Меньше года назад меня вовлекли в проект, для которого необходимо было писать клиента на Flex. Так как я был новичком в этом деле, то в процессе работы я находил что-то новое и совершенно неизвестное мне. В то время я и открыл для себя Flex Data Binding (связыванием данных). Я думаю, что каждый, кто работает с Flex очень скоро сталкивается с Data Binding.
Связывание данных заключается в том, что мы можем с легкостью связывать два объекта (источника данных) между собой, что позволяет поддерживать их синхронизацию. Примером может служить связывание между собой элементов пользовательского интерфейса путем создания некоторых правил поведения, что способствует созданию более интерактивного пользовательского интерфейса.
Имея некоторый опыт в этой области, я решил разобрать все типы механизма связывания данных во Flex. Думаю эта статья будет интересна не только новичкам, но и профессионалы почерпнут из неё что-нибудь для себя.

При разработке на ActionScript, как и на любом другом языке, возникает два вопроса: «В чем писать?» и «Чем собирать?». Если вы продвинутый разработчик, вы наверняка уже используете IntelliJ IDEA как IDE и maven как инструмент сборки. Данная статья показывает оптимальность этого решения и описывает процесс настройки рабочего окружения. Если вы не любите пиво (и не понимаете смысл этой фразы и на кого я только что кивнул) и не считаете себя ленивой скотиной, можете не тратить свое время.

Статья скорее искра, чем пошаговое руководство, тем более, посвящена EAP, поэтому если вы ну совсем ленивая скотина без капли риска, то ждите релиза :)

Перепечатано с моего ЖЖ.

Решился написать про свой опыт изучения английского в экстремально короткие сроки (1 месяц) — вдруг кому пригодится. Также выдам немного инфы про то, как собеседовался за границу.

Решил тут на досуге написать статейку о том, как писать приложения для Android'а. Писать будет простенький тайм менеджер. В этой части я напишу саму программу, приделаю к ней интерфейс с анимацией, а в следующей, если будет интересно, напишу к ней сервис, чтоб программа работала еще и в фоновом режиме.

Что будет рассмотрено:

• RelativeLayout для реализации интерфейса программы с наложением изображений друг на друга.
• Timer для реализации алгоритма подсчета времени.
• Animation для свистоперделок красивого интерфейса апплета.

Для наглядности добавил скринкаст как все это добро работает.

Итак, пишем простенький тайм менеджер для Android'а.

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

Помните пост «Что хабровчане носят с собой», где народ хвастался содержимым своего рюкзака? Меня, если честно, больше интересовало не содержимое, а то, в чем народ носит свои вещи. Вот так, к слову, выглядела одна из наиболее интересных вещей — фотосумка Boomburum.



Сегодня мне бы хотелось зайти к той теме с другой стороны и показать десяток отличных (действительно отличных) сумок на разный вкус, цвет и кошелек.

Это руководство для WPF-разработчиков, стремящихся добиться максимально чёткой картинки в своих приложениях. Графическая система WPF до мозга костей векторная, но конечным результатом её работы по-прежнему является растр. Если не уделить этому факту должного внимания, можно столкнуться с различными сортами «мыла» — паразитными артефактами растеризации. В такой ситуации важно не терять присутствия духа, причины их возникновения вполне рациональны, а методы борьбы достаточно просты и эффективны.

Асинхронность… Услышав это слово, у программистов начинают блестеть глаза, дыхание становится поверхностным, руки начинают трястись, голос — заикаться, мозг начинает рисовать многочисленные уровни абстракции… У менеджеров округляются глаза, звуки становятся нечленораздельными, руки сжимаются в кулаки, а голос переходит на обертона… Единственное, что их объединяет — это учащенный пульс. Только причины этого различны: программисты рвутся в бой, а менеджеры пытаются заглянуть в хрустальный шар и осознать риски, начинают судорожно придумывать причины увеличения сроков в разы… И уже потом, когда большая часть кода написана, программисты начинают осознавать и познавать всю горечь асинхронности, проводя бесконечные ночи в дебаггере, отчаянно пытаясь понять, что же все-таки происходит…

Именно такую картину рисует мое воспаленное воображение при слове “асинхронность”. Конечно, все это слишком эмоционально и не всегда правда. Ведь так?.. Возможны варианты. Некоторые скажут, что “при правильном подходе все будет работать хорошо”. Однако это можно сказать всегда и везде при всяком удобном и не удобном случае. Но лучше от этого не становится, баги не исправляются, а бессонница не проходит.

Так что же такое асинхронность? Почему она так привлекательна? А главное: что с ней не так?

В предыдущей статье мы заглянули внутрь процессора, пусть и гипотетического. Мы выяснили, что для корректного выполнения параллельного кода процессору необходимо подсказывать, до каких пределов ему разрешено проводить свои внутренние оптимизации чтения/записи. Эти подсказки – барьеры памяти. Барьеры памяти позволяют в той или иной мере упорядочить обращения к памяти (точнее, кэшу, — процессор взаимодействует с внешним миром только через кэш). “Тяжесть” такого упорядочения может быть разной, — каждая архитектура может предоставлять целый набор барьеров “на выбор”. Используя те или иные барьеры памяти, мы можем построить разные модели памяти — набор гарантий, которые будут выполняться для наших программ.

В этой статье мы рассмотрим модель памяти C++11.

Как только я заинтересовался lock-free алгоритмами, меня стал мучить вопрос – а откуда взялась необходимость в барьерах памяти, в «наведении порядка» в коде?
Конечно, прочитав несколько тысяч страниц руководств по конкретной архитектуре, мы найдем ответ. Но этот ответ будет годен для этой конкретной архитектуры. Есть ли общий? В конце концов, мы же хотим, чтобы наш код был портабелен. Да и модель памяти C++11 не заточена под конкретный процессор.
Наиболее приемлемый общий ответ дал мне мистер Paul McKenney в своей статье 2010 года Memory Barriers: a Hardware View of Software Hackers. Ценность его статьи – в общности: он построил некоторую упрощенную абстрактную архитектуру, на примере которой и разбирает, что такое барьер памяти и зачем он был введен.
Вообще, Paul McKenney – известная личность. Он является разработчиком и активным пропагандистом технологии RCU, которая активно используется в ядре Linux, а также реализована в последней версии libcds в качестве ещё одного подхода к безопасному освобождению памяти (вообще, о RCU я хотел бы рассказать отдельно). Также принимал участие в работе над моделью памяти C++11.
Статья большая, я даю перевод только первой половины. Я позволил себе добавить некоторые комментарии, [которые выделены в тексте так].

Построение lock-free структур данных зиждется на двух китах – атомарных операциях и способах упорядочения доступа к памяти. В этой статье речь пойдет об атомарности и атомарных примитивах.

Анонс. Спасибо за теплый прием Начал! Вижу, что тема lock-free интересна хабрасообществу, это меня радует. Я планировал построить цикл по академическому принципу, плавно переходя от основ к алгоритмам, попутно иллюстрируя текст кодом из libcds. Но часть читателей требует зрелищ не мешкая показать, как пользоваться библиотекой, особо не рассусоливая. Я согласен, в этом есть свой резон. В конечном счете, и мне не так интересно, что там внутри boost, — опишите, как его применять! Поэтому свой эпический цикл я разделю на три части: Основы, Внутри и Извне. Каждая статья эпопеи будет относится к одной из частей. В Основах будет рассказываться о низкоуровневых вещах, вплоть до строения современных процессоров; это часть для почемучек вроде меня. Внутри будет освещать интересные алгоритмы и подходы в мире lock-free, — это скорее теория о том, как реализовать lock-free структуру данных, libcds будет неисчерпаемым источником C++ кода. В Извне будут статьи о практике применения libcds, — программные решения, советы и FAQ. Извне будет питаться вашими вопросами/замечаниями/предложениями, дорогие хабражители.

А пока я судорожно готовлю начало Извне, — первая часть Основ. Статья во многом не о C++ (хотя и о нем тоже) и даже не о lock-free (хотя без atomic lock-free алгоритмы неработоспособны), а о реализации атомарных примитивов в современных процессорах и о базовых проблемах, возникающих при использовании таких примитивов.
Атомарность — это первый круг ада низкий уровень из двух.

Я надеюсь, что эта статья станет началом цикла заметок о lock-free структурах данных. Я хочу поделиться с хабрасообществом своим опытом, наблюдениям и размышлениями о том, что такое lock-free структуры данных, как их реализовывать, подходят ли концепции контейнеров стандартной библиотеки STL к lock-free контейнерам, и когда стоит (и стоит ли вообще) применять lock-free структуры данных.

Эта статья — частичный перевод одной интересной статьи с sqlite.org, в которой подробно рассматривается реализация транзакций в SQLite. На самом деле я очень редко работаю с SQLite, но тем не менее мне очень понравилось это чтиво. Поэтому если хотите просто развить кругозор — будет интересно почитать. Первые две секции не включены в перевод, так как там нет ничего интересного, да и мне лень их набивать (пост и так огромный).

3.0 Однофайловый коммит

Мы начнём с обзора шагов, которые SQLite предпринимает, чтобы совершить атомарный коммит транзакции, которая затрагивает только один файл базы данных. Детали формата файлов, которые используются для защиты от повреждения БД и техники, которые применяются для коммита в несколько БД будут показаны ниже.

3.1 Начальное состояние

Состояние системы, когда соединение с БД только что было поднято, поверхностно изображено на рисунке справа. Справа показана информация, которая хранится на энерго-независимом носителе. Каждый прямоугольник — это сектор. Синий цвет говорит о том, что этот сектор содержит оригинальные данные. Посередине изображён дисковый кеш операционной системы. В самом начале нашего примера кеш холодный, это изображено белым цветом. На левой части рисунка — содержимое оперативной памяти процесса, который использует SQLite. Соединение с БД только что было открыто, и никакой информации прочитано не было.