Рубрика «atomic»

в 11:15, , рубрики: atomic, atomicity, c++, lock-free, Атомик, атомики

Мотивация

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

Причины существования атомиков

  • data race (гонка данных) — ситуация, когда два или более потоков одновременно обращаются к одной области памяти, причём хотя бы один выполняет запись, и при этом хотя бы один поток не синхронизирован.

Рассмотрим следующий код.
Ссылка на код: https://godbolt.org/z/qWzGreMac.

Читать полностью »

в 8:15, , рубрики: atomic, clickhouse, etl, insert, sql, атомарность, витрины данных, кликхаус

В этой статье мы поговорим о том, как реализовать поведение атомарной вставки в ClickHouse. Рассмотрим несколько вариантов, подсветим их сильные и слабые стороны, а также, когда каждый из них применять.

Задача

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

Неатомарная вставка = риск чтения некорректного набора данных.

Сценарии, когда такое может произойти:

  1. Удалили партицию и хотели начать вставлять данные взамен удалённой, но пользователь обратился к этому интервалу.

    2. Читать полностью »

в 15:16, , рубрики: atomic, c++, concurrency, lock-free, multithreading programming

Многопоточное программирование в C++ традиционно ассоциируется с мьютексами, condition variables и потенциальными проблемами вроде deadlocks и race conditions. Однако современные стандарты C++ (начиная с C++11 и далее) предоставляют инструменты для написания высокопроизводительного многопоточного кода без классических блокировок. В этой статье рассмотрим продвинутые техники: lock-free программирование, атомарные операции и различные модели упорядочивания памяти.

Зачем нужен lock-free код?

Lock-free структуры данных позволяют нескольким потокам работать с общими данными без использования мьютексов. Основные преимущества:

в 9:00, , рубрики: atomic, atomic operation, Go, golang, Mutex, ruvds_статьи
Go: жарим общие данные. Атомно, быстро и без мьютексов - 1

Как правило, в Go для безопасного доступа к общим данным используются мьютексы. Да, каналы тоже можно приспособить для изменения общих данных, так как они потокобезопасны, но это усложняет и замедляет логику.

Но в этой статье мы поговорим о другом. Современные процессоры имеют поддержку атомарных операций, что позволяет на основе них организовывать работу с общими данными до нескольких раз быстрее, чем с помощью общепринятых вариантов. Так как мьютексы реализованы на основе ОС, каналы сделаны на основе внутреннего кода Go с использованием тех же мьютексов из ОС под капотом, а атомарные операции делает сам процессор аппаратно за существенно меньшее количество тактов.Читать полностью »

в 15:10, , рубрики: assembly, atomic, atomics, backend, concurrency, Go, golang, Mutex

Атомики в Go - это один из методов синхронизации горутин. Они находятся в пакете стандартной библиотеки sync/atomic. Некоторые статьи сравнивают atomics с mutex, так как это примитивы синхронизации низкого уровня. Они предоставляют бенчмарки и сравнения по скорости, например Go: How to Reduce Lock Contention with the Atomic Package.

Читать полностью »

в 8:44, , рубрики: atomic, c++, c++ библиотеки, C++20, c++2a, constexpr, Алгоритмы, Блог компании Яндекс, Компиляторы, Программирование, с++ программирование

В начале июня в городе Рапперсвил-Йона завершилась встреча международной рабочей группы WG21 по стандартизации C++.

С++20 на подходе! Встреча в Рапперсвил-Йона - 1

Вот что вас ждёт под катом:

  • Контракты и друзья
  • Концепты (без друзей)
  • __has_cpp_attribute(unlikely)
  • bit_cast<my_stuff>(some_array)
  • contains, shift_left, shift_right, ispow2, ceil2… и старые алгоритмы под новым соусом
  • atomic_ref
  • Что нового можно писать в шаблонах и чем это полезно
  • constexpr virtual foo()
  • Parallelism 2, Reflection и Executors TS

Так же будет бонус: мини секция для экспертов:

  • user-declared virtual destructor не влияет на тривиальность типа
  • Куда можно будет засунуть восклицательный знак и чем это может быть полезно
  • constexpr std::regex mail_regex(R"((?:(?:[^<>()[].,;:s@"]+(?:.[^<>()[].,;:s@"]+)*)|".+")@(?:(?:[^<>()[].,;:s@"]+.)+[^<>()[].,;:s@"]{2,}))")

Читать полностью »

в 8:04, , рубрики: atomic, MESI, volatile, когерентность кэша, кэш CPU, модели согласованности, параллельное программирование, распределенные системы, согласованность кэша, состояние гонки

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

Вы можете удивиться: зачем же разработчику ПО думать о механизме кэширования в CPU? Отвечу. С одной стороны, многие понятия из концепции когерентности кэша непосредственно применимы в распределённых системах и на уровнях изоляции СУБД. Например, представление реализации когерентности в аппаратных кэшах помогает лучше понять разницу в моделях согласованности (консистентности) — отличие строгой согласованности (strong consistency) от согласованности в конечном счёте (eventual consistency). У вас могут появиться новые идеи, как лучше обеспечить согласованность в распределённых системах, используя исследования и принципы из аппаратного обеспечения.

С другой стороны, неправильные представления о кэшах часто приводят к ложным утверждениям, особенно когда речь идёт о параллелизме и состоянии гонки. Например, часто говорят о трудности параллельного программирования, потому что «у разных ядер в кэшах могут быть разные/устаревшие значения». Или что квалификатор volatile в языках вроде Java нужен, чтобы «предотвратить локальное кэширование общих данных» и принудительно «читать/записывать только в основную память».
Читать полностью »

в 6:00, , рубрики: atomic, c++, c++ библиотеки, c++17, IT-стандарты, std::string, Блог компании Конференции Олега Бунина (Онтико), велосипедостроение, Компиляторы, Программирование

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

  • Некоторые делают это для самообучения: берут класс стандартной библиотеки, пишут его сами с нуля, сравнивают то, что получилось, с тем, что есть в стандартной библиотеке — в процессе узнают для себя что-то новое.
  • Некоторые проекты имеют особое требования к коду. В embedded-разработке принято работать без RTTI и без exception, поэтому части стандартной библиотеки, которые используют RTTI и exception, необходимо переписать без них.
  • Редко, но бывает, когда велосипед пишут, потому что могут написать лучше, чем в стандартной библиотеке. Как правило, такие нововведения рано или поздно попадают в стандартную библиотеку.
  • Другим только кажется, что они могут написать лучше, и таких людей больше. Но в процессе они обучаются, выясняют для себя что-то новое и что-то интересное открывают.
  • Могут быть другие причины.

Сегодня мы не будем говорить о том, что велосипеды — это плохо, это не обязательно так. Мы поговорим о том, что действительно плохо:

  • бездумно переносить устаревшие технологии 20-30-летней давности в современные проекты;
  • пользоваться «вредными» бенчмарками и оптимизациями.

А также затронем «вредные» советы, обсудим новейшие практики программирования (C++ 11 и позднее), подумаем, что делать с «идеальным» велосипедом.

Читать полностью »

в 11:55, , рубрики: atomic, c++, c++ библиотеки, c++17, C++20, c++2a, constexpr, IT-стандарты, modules, networking, operators, Блог компании Яндекс, Компиляторы, Программирование

Из центральной части Канады — на юго-запад США! Альбукерке расположен в штате Нью-Мексико:

Ещё один шажок к C++20. Встреча в Альбукерке - 1

На встрече международного комитета по стандартизации C++, которая прошла в этом городе, приняли одно очень большое нововведение в С++20 и несколько маленьких.Читать полностью »

в 21:44, , рубрики: atomic, c++, c++11, C++14, high performance, low-latency, memory barrier, memory model, высокая производительность, параллельное программирование, Программирование

В этой статье мы детально разберем атомарные операции и барьеры памяти C++11 и генерируемые ими ассемблерные инструкции на процессорах x86_64.
Далее мы покажем как ускорить работу contfree_safe_ptr<std::map> до уровня сложных и оптимизированных lock-free структур данных аналогичных по функциональности std::map<>, например: SkipListMap и BronsonAVLTreeMap из библиотеки libCDS (Concurrent Data Structures library): github.com/khizmax/libcds
И такую многопоточную производительность мы сможем получить для любого вашего изначально потоко-небезопасного класса T используемого как contfree_safe_ptr<T>. Нас интересуют оптимизации повышающие производительность на ~1000%, поэтому мы не будем уделять внимание слабым и сомнительным оптимизациям.
Читать полностью »

12
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js