. Ну реально, какое отношение имеет "засыпание потока" к "блокировке исполнения"? Да никакого. Поток может и без засыпания бесконечной долбёжкой заблокировать другие потоки навсегда даже при lock-free.
Тем не менее - именно такое общепринятое толкование Non-blocking algorithm. Если в вашей статье подразумевается какое-то другое, дайте пожалуйста ссылку на определение.
Число циклов для инкремента счётчика в лучшем случае (если применяется балансировка) пропорционально числу ядер.
Это зависит, конечно, от архитектуры, но на популярных если ядро владеет кеш линией (exclusive) инкрементирование счетчика бесплатно. Для других ядер будет пенальти.
А что толку от доставленного сообщения, если битва уже произошла? Слишком поздно доставленное сообщение может быть уже никому не интересно.
Т.е. вы считаете, что нет приниципаильной разницы между синхроным и ассинхронным вызовом, надежной и ненадежной доставкой?
Вы считаете, что классификация описанная в статье и книге "The Art of Multiprocessor Programming" неудачная? Приведите, пожалуйста, аргументы почему.
Собственно в примерах кода вы там можете у локфри наблюдать бесконечный цикл, что эффективно является блокировкой
Нет, blocking, lock-free, wait-free это про гарантии прогресса алгортима, а не время обработки. В случае блокировок если процесс/поток захвативший лок зависнет, никакой другой поток не сможет продолжить, в отличие от lock-free который выполнится за конечное число шагов.
Атомарное изменение счётчика приводит ко блокировке на уровне процессорных ядер на сколько я понимаю. Ведь это read-modify-write операция.
И тем не менее - это wait-free операция, которая завершится за определенное количество циклов.
Доставка может и гарантирована, но вот время этой доставки варьируется. А задержавшееся слишком на долго сообщение малоотличимо от недоставленного.
Это как? Я вычитал значение переменной и оно как-то не доставилось или слишком долго? Операция чтения из памяти может потребовать разное количество циклов для завершения, но когда оно закончится значение будет гарантировано доставлено.
Очень странно что вам странно читать про задачу генералов
Да, потому что задача про византийских генералов - это задача в которой присутствует ненадежный канал связи который не доставляет(или подменяет) сообщения. В процессорах такой проблемы нет.
Тут стоит обратить внимание на путаницу в терминах. Lock-free алгоритмы раньше назывались неблокирующими. Теперь же они считаются лишь частным случаем неблокирующих. Но на самом деле это всё же механизм хоть и оптимистичной, но блокировки.
Wait-free алгоритмы межпоточного взаимодействия основаны на той же идее — отсутствие конкуренции за общий ресурс.
В общем случае - это не так. Например атомарное изменение счетчтка - это wait free операция над общим ресурсом.
ИМХО, это была неудачная идея смешивать в кучу concurrency и распределенные системы. Несмотря на то, что многопроцессорную систему можно рассматривать как распределенную, здесь есть принципиальное отличие: соединение между узлами надежное и доставка сообщений по шине гарантирована. С точки зрения CPU нет никакой неопределенности, каждый узел находится в состоянии определенном протоколом (MESI, MOESI, etc.) и система всегда находится в состоянии консенсуса. Поэтому читать про проблему византийский генералов сразу после секции о многопоточности весьма странно.
.
Т.е. упорядочиваются все операции чтения/записи в конкретную атомик переменную.
На уровне x86 CPU — это означает синхронизацию(очистка store-buffer) конкретной кеш линии с переменной, а не вообще всей памяти.
Если барьеры на кеши других ядер не влияют, тогда в чем их смысл на ARM, что они делают? Ведь ядро которое производило запись и так видит все свои локальные изменения.
Это не соотвествует действительности. Так было бы если использовался std::atomic_thread_fence. В данном случае атомарный доступ к флагу никак не влияет на видимость полей g_data1, g_data2, g_data3. Более того, даже компилятор может вызовы местами переставить.
В принципе могут . А как имея базовый класс oAnimal выяснить этот же факт? В простом дизайне по дефолту fleas = 0 и это уже зависит от контекста каким образом это значение может/не может измениться.
Забавно, но на картинке где «ООП, которое пользователи заявляют» идеальный пример как не стоит моделировать. Вместо иерархии классов достаточно иметь один класс где ноги, тип животное/человек, блохи — это всего лишь аттрибуты.
Даже если каждый зарегестрированный пользователь зайдет на сайт в одно и тоже время он должен делать приблизительно 1 клик в секунду. Есть большие сомнения, что online хотя 10% их пользователей.
Интересно, зачем Linkedin было необходимо ворачать несколько террабайт сообщений в час? Это ведь не видеохостинг, а текстовыми сообщениями добиться таких обьемов не реально.
protobuf wire формат поддерживает опциональные поля и в proto v2 — это во всю использовалось. Из версии 3 — это поддержку убрали зачем-то из описания формата. Но поскольку wire формат не изменился, теоретически, можно попрежнему проверять было ли поле установленно или нет.
SBE не использует компрессию для чисел и int32 всегда занимает 4 байта, кроме того нет опциональных полей (кроме определенных случаев), поэтому SBE по факту всегда будет больше.
SBE — это про скорость и пропускную способность, а не про размер и удобство. SBE один из самых быстрых из существующих сериализаторов/десириализаторов с пропускной способностью близкий к пропускной способности шины памяти. Основной сценарий его использования — реалтайм котировки, а не API общего назначения.
Я бы отметил кодек Cap'n Proto от автора Protobuf. Он достаточно быстрый, без лишних копирований, с гибкой схемой версионирования.
Тем не менее - именно такое общепринятое толкование Non-blocking algorithm. Если в вашей статье подразумевается какое-то другое, дайте пожалуйста ссылку на определение.
Это зависит, конечно, от архитектуры, но на популярных если ядро владеет кеш линией (exclusive) инкрементирование счетчика бесплатно. Для других ядер будет пенальти.
Т.е. вы считаете, что нет приниципаильной разницы между синхроным и ассинхронным вызовом, надежной и ненадежной доставкой?
Вы считаете, что классификация описанная в статье и книге "The Art of Multiprocessor Programming" неудачная? Приведите, пожалуйста, аргументы почему.
Нет, blocking, lock-free, wait-free это про гарантии прогресса алгортима, а не время обработки. В случае блокировок если процесс/поток захвативший лок зависнет, никакой другой поток не сможет продолжить, в отличие от lock-free который выполнится за конечное число шагов.
И тем не менее - это wait-free операция, которая завершится за определенное количество циклов.
Это как? Я вычитал значение переменной и оно как-то не доставилось или слишком долго? Операция чтения из памяти может потребовать разное количество циклов для завершения, но когда оно закончится значение будет гарантировано доставлено.
Да, потому что задача про византийских генералов - это задача в которой присутствует ненадежный канал связи который не доставляет(или подменяет) сообщения. В процессорах такой проблемы нет.
Здесь нет никакой путанницы, есть вполне четкие определения для блокирующих и lock-free алгоритмов. Можно например почитать здесь: Lock-Free and Wait-Free, definition and examples.
В общем случае - это не так. Например атомарное изменение счетчтка - это wait free операция над общим ресурсом.
ИМХО, это была неудачная идея смешивать в кучу concurrency и распределенные системы. Несмотря на то, что многопроцессорную систему можно рассматривать как распределенную, здесь есть принципиальное отличие: соединение между узлами надежное и доставка сообщений по шине гарантирована. С точки зрения CPU нет никакой неопределенности, каждый узел находится в состоянии определенном протоколом (MESI, MOESI, etc.) и система всегда находится в состоянии консенсуса. Поэтому читать про проблему византийский генералов сразу после секции о многопоточности весьма странно.
Modern CMake рекомендует использовать таргеты. Т.е.:
target_sources(test PRIVATE main.cpp component1.cpp component2.cpp)
Можно получить список файлов:
$<TARGET_PROPERTY:test , SOURCES>
Kafka streams - это тоже не rocket since +- тоже самое по факту.
И что плохого в том что работает на броекре, а не на клиенте? ИМХО, так даже быстрее, поскольку убирается прокачка данных на клиент.
2). Аналог Kafka streams в пульсаре - это Pulsar function (https://pulsar.apache.org/docs/en/functions-overview/)
Т.е. упорядочиваются все операции чтения/записи в конкретную атомик переменную.
На уровне x86 CPU — это означает синхронизацию(очистка store-buffer) конкретной кеш линии с переменной, а не вообще всей памяти.
Сегодня нет, завтра есть. Про то и речь, что предложенная модель плохо подходит для расширения функуционала.
Кроме того выяснять наличие блох с помощью instanceof — это прямое нарушение LSP.
Если моделирование бизнес области требует, можно заменить блох на котейнер «Паразиты», где блохи один из возможных вариантов.
readonly пользователи врядли создают нагрузку для которой нужна кафка. Если же создает, то интересно почему и архитектурные детали.
Поскольку профили меняются редко, основное это отсылка сообщений размером 500-2000 байт.
А что такое int4?
SBE — это про скорость и пропускную способность, а не про размер и удобство. SBE один из самых быстрых из существующих сериализаторов/десириализаторов с пропускной способностью близкий к пропускной способности шины памяти. Основной сценарий его использования — реалтайм котировки, а не API общего назначения.
Я бы отметил кодек Cap'n Proto от автора Protobuf. Он достаточно быстрый, без лишних копирований, с гибкой схемой версионирования.