User
Небольшая подборка веществ помогающих нашим мозгам работать чуточку лучше. Большинство из них продается в ближайшей аптеке, отпускается без рецепта, имеют доказательную базу и плюс-минус универсальны, так как «качают» самое важное — мотивацию, энергию и память.
Украинский профильный ресурс DOU.UA опубликовал статью о нелегком пути релокации специалиста в США во время пандемии, где он также отвечает на дополнительные вопросы и комментарии.
Адам Леос — Senior Software Engineer в Roku. Пару лет назад он принял решение о релокации и в итоге выбрал своей целью США. Всего за три месяца Адам с нуля собрал все необходимое для подачи на визу О1, но потом в историю вмешалась пандемия. О том, с какими трудностями он столкнулся из-за карантина, как искать работу на американском IT-рынке, как получить большое количество офферов и выторговать самую выгодную компенсацию, разработчик рассказал в интервью DOU.UA
Разработчики часто сталкиваются с необходимостью разработки многопоточных приложений, поэтому вопросы многопоточности требуют детального изучения. Давайте познакомимся с основными терминами, используемыми в источниках информации о многопоточности, рассмотрим задачи и проблемы многопоточности и изучим средства стандартной библиотеки C++, которые помогут создавать многопоточные приложения.
В первых двух статьях цикла мы рассмотрели четыре способа упорядочить доступ к памяти: load-acquire и store-release операции в первой части, барьеры чтения и записи в память — во второй. Теперь пришла очередь познакомиться с полными барьерами памяти, их влиянием на производительность, и примерами использования полных барьеров в ядре Linux.
Рассмотренные ранее примитивы ограничивают возможный порядок исполнения операций с памятью четырьмя различными способами:
Внимательный читатель заметил, что одна из возможных комбинаций в этом списке отсутствует:
| Чтение выполняется... | Запись выполняется... | |
| … после чтения | smp_load_acquire(), smp_rmb() | smp_load_acquire(), smp_store_release() |
| … после записи | ??? | smp_store_release(), smp_wmb() |
Это ознакомительная статья о языке программирования Rust и его инструментах, с помощью которой я надеюсь привлечь ваше внимание к этому интересному и уникальному языку, созданному чтобы дать ответ на следующие вопросы разработчиков:
Как убедиться, что в моем приложении нет проблем и уязвимостей, связанных с неправильной работой с памятью? Как быть уверенным в том, что любой доступ к общим объектам правильно защищен? Как свести к минимуму любую работу, не связанную напрямую с написанием кода?
Цель данной статьи не рассказать о доселе невиданных возможностях Rust (сразу говорю, что тут ничего нового "Растоманы" не найдут), на Хабре вы итак найдете множество интересных статей о внутренностях языка и интересных случаев использования. Моя цель рассказать о том, что он предлагает в качестве решения обозначенных выше проблем, как это будет выглядеть со стороны программиста, и почему это важно.
1) начинающих реверсеров, знающих особенности обратного проектирования, и желающих изучить такой отладчик как GDB
2) как подсказка тем кто постоянно работает с IDA, Ghidra или любым другим мощным и надежным инструментом, но в силу тех или иных обстоятельств решить задачу проще и быстрее с помощью GDB, и не очень хочется залезать в официальную документацию и снова все вспоминать
Отладка makefile - это что-то из черной магии. К несчастью, не существует такой вещи как makefile отладчик, чтобы изучить ход выполнения конкретного правила или как разворачивается переменная. Большую часть отладки можно выполнить с помощью обычных print’ов и проверкой makefile. Конечно, GNU make немного помогает своими встроенными методами и опциями командной строки. Один из лучших методов отладки makefile это добавить отладочные перехваты (hooks) и использовать техники безопасного программирования, на которые можно будет опереться, когда дела пойдут совсем плохо. Далее представлено несколько основных техник отладки и практик безопасного программирования, которые будут, на мой взгляд, наиболее полезными.
Для написания эффективных и корректных многопоточных приложений очень важно знать какие существуют механизмы синхронизации памяти между потоками исполнения, какие гарантии предоставляют элементы многопоточного программирования, такие как мьютекс, join потока и другие. Особенно это касается модели памяти C++, которая была создана сложной таковой, чтобы обеспечивать оптимальный многопоточный код под множество архитектур процессоров. Кстати, язык программирования Rust, будучи построенным на LLVM, использует модель памяти такую же, как в C++. Поэтому материал в этой статье будет полезен программистам на обоих языках. Но все примеры будут на языке C++. Я буду рассказывать про std::atomic, std::memory_order и на каких трех слонах стоят атомики.
Как быть, если дерево поиска разрослось на всю оперативку и вот-вот подопрет корнями соседние стойки в серверной? Что делать с инвертированным индексом, жадным до ресурсов? Завязывать ли с разработкой под Android, если пользователю прилетает «Память телефона заполнена», а приложение едва на половине загрузки важного контейнера?
В целом, можно ли сжать структуру данных, чтобы она занимала заметно меньше места, но не теряла присущих ей достоинств? Чтобы доступ к хэш-таблице оставался быстрым, а сбалансированное дерево сохраняло свои свойства. Да, можно! Для этого и появилось направление информатики «Succinct data structures», исследующее компактное представление структур данных. Оно развивается с конца 80-х годов и прямо сейчас переживает расцвет в лучах славы big data и highload.
А тем временем на Хабре найдется ли герой, способный пересковоговорить три раза подряд
[səkˈsɪŋkt]?
