В первых двух статьях цикла мы рассмотрели четыре способа упорядочить доступ к памяти: load-acquire и store-release операции в первой части, барьеры чтения и записи в память — во второй. Теперь пришла очередь познакомиться с полными барьерами памяти, их влиянием на производительность, и примерами использования полных барьеров в ядре Linux.

Рассмотренные ранее примитивы ограничивают возможный порядок исполнения операций с памятью четырьмя различными способами:

• Load-acquire операции выполняются перед последующими чтениями и записями.
• Store-release операции выполняются после предыдущих чтений и записей.
• Барьеры чтения разделяют предыдущие и последующие чтения из памяти.
• Барьеры записи разделяют предыдущие и последующие записи в память.

Внимательный читатель заметил, что одна из возможных комбинаций в этом списке отсутствует:

В этой статье мы подробно разберем понятие сопрограмм (coroutines), их классификацию, детально рассмотрим реализацию, допущения и компромиссы, предлагаемые новым стандартом C++20.

В последнее время разработчики электроники испытывают трудности с поставками электронных компонентов. Одним из решений данной проблемы является переход на "исконно китайскую" элементную базу. Это решение подкупает ценой и доступностью, но пугает плохой документацией и небольшим количеством информации на понятных нам языках. В данной публикации расскажу о любопытном микроконтроллере на ядре RISC-V и сделаю простое первое устройство - датчик концентрации углекислого газа в воздухе/мигалку OLED дисплеем и светодиодом (куда ж без мигалки светодиодом). В репозитории размещен проект для тех, кто захочет воспользоваться данными наработками.

Всех приветствую!

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

Мне очень понравилась работа команды, создавшей Flipper Zero. Став обладателем этого устройства, в процессе эксплуатации я пришёл к выводу, что оно очень полезно, но, на мой взгляд, недостаточно удобно в эксплуатации ввиду наличия только джойстика для управления этим устройством. Да, можно подключить отдельную плату расширения с нужным количеством кнопок для быстрого набора цифровых данных, но… Очень захотелось, чтобы на одном устройстве было всё максимально удобно для использования, и чтобы это максимальное удобство не занимало много места. Так как я - человек, детство которого прошло во времена Советского Союза, я стал свидетелем вхождения в наш обиход первых мобильных телефонов, тех самых легендарных Motorolа, SonyEricsson, Nokia, и мне очень захотелось создать нечто похожее по функционалу на Flipper Zero, но в то же время напоминающее те самые первые мобильники… Ностальгия, так сказать…

Программированием микропроцессоров я занимаюсь с начала 2000-х годов, со времен своего студенчества, и именно тогда у меня родилась интересная идея – а почему бы не попробовать сделать свой, особенный, телефон, с моим «сердцем» внутри - взять за основу один из тех самых легендарных телефонов и расположить всё то, что я хочу, в нём!

 Бороздя просторы Интернета и воскрешая в памяти все эти сейчас уже ставшие легендами первые мобильники, я неоднократно наталкивался на хохмы про телефон Nokia 3310. Как-то на выходных, разобрав пару-тройку полок в своём гараже, я отыскал ЕГО, телефон, который когда-то, в году эдак 2002-ом, а может, и в 2003-м, был самой настоящей гордостью студента!

Прочитав эту статью вы узнаете:

1. Способы, которыми можно продлить время жизни временного объекта в С++.

2. Рекомендации и подводные камни этого механизма, с которыми может столкнуться С++ программист, и с которыми сталкивался на работе я.

Информация из статьи может быть полезна как новичкам, так и профессионалам.

Если заинтересовало, то самое время налить чая, и погнали разбираться где тут референсы висят.

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

В стандартную библиотеку C++ входит несколько контейнеров. Кроме этого, в Open Source есть несколько контейнеров, которые покрывают больше юзкейсов. Я опишу устройство интересных контейнеров вне STL и их отличия от классических контейнеров.

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

Работа со старым кодом для многих команд является частью повседневных обязанностей. За свою карьеру я видел и применял разные способы борьбы с тяжестью легаси. Они обычно сводились к одному из трёх основных сценариев:

«Работает — не трогай!»: вообще забить на чистки и ничего не менять. В некоторых случаях валидный подход. Но в коде, который приходится менять хотя бы даже эпизодически (фиксы багов, мелкие доделки, смена окружения и т. п.), со временем неизбежно приводит к катастрофе. Вам надо что‑то поменять в коде, и это оказывается невозможно сделать легко. Даже за тривиальные изменения приходится платить большой кровью.

«Я прочитал Роберта Мартина»: включаем чистки в обычный код. Надеваем галстук бойскаута и чистим код прямо по ходу работы над текущими задачами. Отправляем его коллегам на ревью и ждём несколько дней, покуда они не разберутся, где заканчиваются рефакторинги и начинаются непосредственно изменения по задаче. Или же уходим по кривой дорожке рефакторингов в тёмный лес и продалбываем к чертям все изначальные сроки. Когда начинаешь приводить код к идеалу, не всегда бывает так легко остановиться!

«Нужен порядок и учёт»: делаем отдельные коммиты с чистками, но нерегулярно — только когда в дело берётся соответствующий тикет. Правда, тикеты на рефакторинг почему‑то регулярно получают самый низкий приоритет во время планирования и маринуются в беклоге месяцами. Но что уж тут поделать?

Это всё ловушки! Все эти сценарии страдают одной общей проблемой: темп чисток неудовлетворительно низок. Код зарастает грязью и происходит неизбежная деградация. Задачи делаются всё медленнее, процент дефектов всё выше, отвращение от работы с кодом растёт, новички адаптируются всё медленнее и медленнее. Все несчастны и не знают, что делать.

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

В программировании микроконтроллеров часто нужно написать простые тестировочные прошивки. При этом надо некоторые функции вызывать чаще, а некоторые реже. Для этого, конечно, можно запустить FreeRTOS, однако тогда этот код не будет переносим на другие RTOS например Zephyr RTOS или TI-RTOS. Поэтому надо держать наготове какой-нибудь простенький NoRTOS планировщик.

В этот тексте я представил основные идеи алгоритма такого кооперативного планировщика.

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

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

Я исследовал некоторые open-source фреймворки — кандидаты на платформу для опорной сети пятого поколения операторского уровня, и хочу поделиться своими выводами. Под катом я сравню Seastar, mTCP, Boost.Asio, userver и ACE, расскажу, почему примитивы синхронизации — это плохо, а затем погружу вас в глубины Seastar.

Доброго времени суток, коллеги. Я по-прежнему являюсь разработчиком ISPsystem, и меня все еще зовут Дмитрий Смирнов. Некоторое (довольно продолжительное) время я никак не мог определиться с темой следующей публикации, поскольку материала за последние месяцы работы с Boost.Asio накопилось много. И уже в тот момент, когда казалось, что легче подбросить монетку, одна задача все изменила. Нужно было разработать инструмент, позволяющий frontend’у фильтровать данные в запрашиваемых списках. Сам же список со стороны backend'а представляет собой обыкновенный json_array. Добро пожаловать под кат, там все взлеты и падения последних дней.

Сегодня мы изготовим простой и бюджетный DIY-дозиметр на базе wifi-контроллера ESP32 и платы RadSens. В качестве сенсора будет использована популярная трубка СБМ20. 

Целью статьи является создание максимально подробной инструкции по сборке. Если повторить описанные шаги сможет самый юный инженер-дозиметрист - мы достигли успеха.

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

Коротко обо мне. Меня зовут Макс, и так получилось, что я вот уже 10 лет, почти с самого начала своей карьеры, занимаюсь оптимизирующими компиляторами. Я начинал в Intel, потом перешёл в Azul Systems, год провёл в Cadence и вернулся обратно, всё это время занимаясь компиляторными оптимизациями для Java, C++ и нейросетевых моделей. На момент написания статьи у меня чуть за 900 патчей в LLVM, большинство из них посвящено цикловым оптимизациям.

За это время я провёл десятки собеседований на позиции как интернов, так и инженеров сеньорного уровня, и довольно часто люди, приходя на эти собеседования, многих вещей не знают или знают поверхностно. И я подумал: а мог бы я написать такой цикл статей, чтобы человек, прочитав их, узнал бы всю ту базу, которая, на мой собственный взгляд, необходимо начинающему компиляторному инженеру? Очень бы хотелось, чтобы новичку в этой области можно бы было дать один (относительно небольшой по объёму) набор текстов, чтобы он получил оттуда всё необходимое для старта. Это не перевод, текст оригинальный, поэтому в нём могут быть ошибки и неточности, которые я буду рад исправить, если вы мне их укажете.

Итак, поехали.

Привет, Хабр! Меня зовут Дмитрий Луцив, я работаю в СПбГУ на кафедре системного программирования, веду ряд IT-дисциплин на математико-механическом факультете в лабаратории компании YADRO и помогаю вузам актуализировать образовательные программы под задачи индустрии.

Я давно не программировал на С++, но стараюсь не отставать от изменений, происходящих в языке. Книга «C++ 20 в деталях» заинтересовала меня личностью автора (на секунду, это Райнер Гримм) и возможностью познакомиться с новым источником знаний о «плюсах». Решил ее прочитать, чтобы понять, кому материал будет полезен и могу ли я его рекомендовать. Под катом расскажу, что в книге хорошего, а что можно было бы сделать лучше, а также дам список дополнительных источников для специалистов разного уровня.

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

В нашем полифункциональном заряднике есть небольшой графический дисплей. Разберём что тут можно подобрать. 

Здравствуйте! Меня зовут Александр, я работаю инженером-программистом микроконтроллеров.

Пишу на С/С++, причем предпочитаю плюсы, ибо верую в их эволюционную неизбежность в embedded.

Мир встроенного ПО, язык С++ динамично развиваются, поэтому разработчикам важно не отставать и поддерживать свои скиллы и наработки актуальными моменту.

Я стараюсь следовать этому очевидному посылу, благо небожители ведущие С++ программисты и консультанты щедро делятся своим опытом и идеями на разных площадках (например здесь, или здесь).

Некоторое время назад я посмотрел мощный доклад Сергея Федорова про построение конечного автомата с таблицей переходов на шаблонах.

Для написания эффективных и корректных многопоточных приложений очень важно знать какие существуют механизмы синхронизации памяти между потоками исполнения, какие гарантии предоставляют элементы многопоточного программирования, такие как мьютекс, join потока и другие. Особенно это касается модели памяти C++, которая была создана сложной таковой, чтобы обеспечивать оптимальный многопоточный код под множество архитектур процессоров. Кстати, язык программирования Rust, будучи построенным на LLVM, использует модель памяти такую же, как в C++. Поэтому материал в этой статье будет полезен программистам на обоих языках. Но все примеры будут на языке C++. Я буду рассказывать про std::atomic, std::memory_order и на каких трех слонах стоят атомики.