то никто не знает - не нажму ли я еще и "F", поэтому первый shortcut срабатывать еще не должен.
И Linux и Windows умеют отличать обработчики событий и по нажатию, по отпусканию. Но вот в Linux разработчики именно переключателя раскладки почему-то уперлись в нажатие. Почему так, не вникал, это уже годами не лечится.
Но и в Windows тоже было не все ок с этим. Мне в бытность пришлось в VSCode принудительно переназначить все Ctrl+Shift+<чтототам>, потому что случались ложные срабатывания переключателя раскладки. Т.е. собирался что-то там сделать, нажал Ctrl+Shift, в последний момент передумал, отпустил - бац, и уже пишешь код кириллицей.
Не то что часто такое происходило, но тоже раздражало. Впрочем, само понятие шотката на три кнопки - уже клинический случай, их все равно нужно было переназначить.
Слишком сильно сильный грохот по ночам :) И не сильно совместимо со слепой печатью. Одно дело оттопыренным мизинцем нажимать CapsLock, другое дело - этим левым мизинцем попытаться попасть в Win/Cmd этот (а он в три раза меньше Caps), а потом еще и в Space большим пальцем.
Ctrl+Shift и то были удобнее - их можно было сразу две одним мизинцем нажать (именно по этой причине выбешивала "стандартная" двухпацльцевая растопырка Alt-Shift, в которую нужно было целиться двумя пальцами, т.е. сбивать режим слепой печати).
но разумнее было бы настроить переключение раскладки по отпусканию управляющих клавиш.
Нет, это ментальная ловушка как в анекдоте про апельсин, клетку и обезьян, брандспойт и "так так принято".
Т.е. любой ценой достичь того, к чему привык в Windows. Но это все равно что ходить шатать трубу на тему "а чего это у вас тут C: D: E: нет, и вообще каталоги через /, а не через \, срочно, срочно все пропатчить!"
Не надо так делать. Нужно просто расслабиться, пересесть на CapsLock как переключатель раскладки клавиатуры - и через пару недель "стандартные" виндовые Alt+Shift и Ctrl+Shift будут выбешивать в разы сильнее, чем CMD.EXE после bash.
Хотя случаи бывают разные. Возможно кто-то карьеру на CMD.EXE/PowerShell построил и подобный аргумент не оценит.
Да, вот именно, что не принципиально. Но есть вопрос удобства.
Теперь задаемся вопросом - а почему нужно переключать двухклавишной комбинацией? Кто решил что это удобно? Ctrl+Shift, Alt+Shift, Win+Space - вот кто именно придумал подобные способы? Есть подозрение, что это были те, кто 99.999% времени сидит на английской раскладке, ничем иным такое иезуитство не объяснить.
Дальше больше - Ок, мы осознали, что переключать можно было бы и одной клавишей, мизинцем, а не принудительной двухпальцевой раскорячкой. Теперь идем по клавиатуре и смотрим "незадействованные" кандидаты.
Win/Meta занята. Есть еще странная кнопка "меню" справа от правой Win/Meta. Но она есть не на всех клавиатурах. ScrollLock еще, но до нее тянуться очень долго. И она мелкая, хрен попадешь. А на некоторых ноутбуках отсуствует. Получается единственно реально общедоступной и свободной от полезных функций кнопкой является CapsLock.
И физически CapsLock выглядит хорошо. Он большой, удобно лежит под левым мизинцем. Применяется? В обычной жизни "применяется" лишь для режима "балин, опять случайно включился, забой, забой, забой, тааак... выключаем. Выключился? Балин, еще раз". Потому ей реально никто и не пользуется. ДАЖЕ ЕСЛИ НАДО ПОКРИЧАТЬ - то это делается комбинацией "задавили мизинцем Shift и печатаем остальными пальцами"
Потому просто переделываем CapsLock на переключатель раскладки и радуемся жизни. В линуксе это очень просто (какой-то gnone-tweak-tool, не помню уже, делается один раз при установке, элементарно гуглится по "centos|ubuntu|arch switch caps layout").
Может быть те люди, которые 99.999% времени сидят на английской раскладке - догадаются сделать это по дефолту, но сомнительно. Скорее всего они у себя там в US КРИЧАТ через CapsLock, и им это прям очень важно, поди пойми этих американцев.
P.S. А еще можно было бы ножную педаль придумать, как на рояле. Но готовых вариантов почему-то никто не продает.
что если есть язык, специально предназначенный для решения какого-то класса задач, то решать эти задачи на нем и проще
Поздравляю парни, да вы открыли понятие DSL!
А любой DSL можно на любом другом языке реализовать. Хоть на Python, хоть на C++, да хоть на JSON.
И это не проблема "базового" языка, это проблема продуманности (или, что чаще встречается - непродуманности и/или излишней абстрактности-заумности) предлагаемых API и прочих специфичных задаче сниппетов и структур.
Применительно к С++ это и вовсе означает очевидное - пора выбросить многовековое нагромождение шаблонных несуразиц по имени STL как "стандарт", которое задает тон всем остальным библиотекам, и заменить чем-то более простым, понятным, адекватным и современным. Взяв лучшее от "C++ вытеснителей".
Тема Ctrl+Shift против Caps уже обсуждалась сотни раз даже на хабре. Не надо в Линуксе Ctrl+Shift, после недели на Caps гуглится Recaps и наступает всеобщее счаcтье и понимание, что это в Windows все изначально не так было сделано.
Аналогично порвали десятки баянов на теме KDE vs XFCE vs Gnome (который плагинами кстати тоже можно довести до внешнего вида Win10 https://extensions.gnome.org/#sort=downloads Dash to Panel, Arc menu и т.д.).
Новизна статьи поста вообще в чем? Что в Linux можно работать не только через putty? А то блин мужики и не знали :)
QNX (тоже сильно сложно, но все же POSIX система).
Трудно сказать, ни разу ее в деле нигде даже на стенде не видел, только в статьях и книжках. Где она вообще применяется? В автомобилях на панелях можно увидеть Android, Windows (иногда, на старых авто особенно). А в микроконтроллеры она не влезет.
Solaris (аналогично - условно POSIX) до сих пор актуальна.
Актуальна в режиме доживания в корпоративе, где она в основном и применялась. Проекты по миграции на RHEL или на SLES уже много лет являются трендом. Даже сам Oracle активно форсирует свой OEL как замену. SPARC это уже больше экзотика, последнее что там было новационное - это нативная поддержка Oracle Database арифметики (вариации BCD NUMBERS), и то, Oracle проще будет с ARM договориться (туда все и идет).
Похороненная и живущая только в комментариях на LORе BSD (туда же) основа для Playstion. Ах да, еще macOs корнями упирается в нее же.
Playstation это прям сильно нишевое. Игроделы ЕМНИП работают и вовсе на платформо-независимых абстракциях. А MacOS актуальна разве как запускалка AutoCAD и MS Office, которые почему-то до сих пор под Linux не портировали. Ну и Dockerа. Хотя безусловно есть любители разработки и чисто под MacOS, но POSIXом там явно не ограничивается, мягко говоря.
У Linux есть GPL и надзорные органы, которые не очень эффективно, но следят за ее соблюдением. Потому про Linux знают. Можно долго спорить, но "вирусная лицензия" GPL сильно мешает вашему же "могут ... все нужные linux specific APIs реализовать"
Насколько я помню даже Oracle не получилось Java APIs в суде отстоять, хотя денег туда в суды вбухали порядочно. А что, действительно ходят и пальчиком грозят, что использовать Linux APIs никак нельзя? Я как-то краем глаза видел, что во FreeBSD пытались нативно Linux ELFы запускать, кажется вот про это https://docs.freebsd.org/en/articles/linux-emulation/
Никто вроде не приходил трубу шатать, возможно я пропустил что-то.
Безусловно, основной прогресс в Linux. Причем прогресс настолько огромный, что уже начинает попахивать цепной реакцией и не очень понятно найдется ли на нее контролирующий стержень. Впрочем, это уже тема отдельного разговора. И я не хочу его начинать.
А что так? Личная боль в виде растраченных инвестиций в Solaris? Я вот сейчас уже даже и не припомню каких-то особо уникально полезных APIs в Solaris, аналогов которых в Linux не было (про обратное сказать не получится). Но они точно были, миграции проходили не в режиме перекомпилировали, подкинув врапперов и ifdefов и поехали.
Так с этого и надо было сразу начинать (сразу и закончить), а не пытаться "уровни" подготовки и прочие личностные оценочные суждения по щекам размазывать, право.
Даже если просто читать внимательно, то уже очевидно. А если еще и хоть слегка в теме, то и подавно.
Я так понимаю примеров эффективного решения задач с высококонкурентным параллелизмом на тредах (а не банальных MPP с тотальной изоляцией workerов и их окружения) мы не дождемся?
Давно-не подавно. Это все не интересно. Мне интересен лишь один простой вопрос - насколько реально нужны именно треды с мутексами и можно ли их заменить на взаимно изолированные процессы в один поток с message passing, как универсальную архитектуру в общем случае.
Почему интересно - чисто как мотивация упростить базовые APIs в фреймворке, выбросив примитивы многотредовой синхронизации (начиная с pthread) вообще как понятие, ограничившись лишь CAS (а то и вовсе memory barrier) на inter-process message passing.
Сказки про то, кто там теме и не в теме и прочий подобный детский садик - это не интересно. Просто хочется услышать реальный внятный пример, дескать а вот тут треды и мутексы нам были очень нужны, без них вообще никак, прям беда беда без них, огорчение.
Уже несколько лет пытаюсь найти подобные задачи, ни разу не встречались (а вот эффективные MPP с тотальной изоляцией исполнителей встречались постоянно, тут и спорить нечего)
И заявлять о том, что multi-threading не имеет отношения к производительности даже не уточнив о какой именно области идет речь -- это "мощно, внушаить!" (c)
Чем минусы ставить - читать стоит сначала. Там было сказано - обычно не имеет. Имелось в виду тех самых задачах concurrent computing и blocking I/O.
PS. Очевидно, что @SpiderEkb в своих комментариях выше говорил о parallel computing.
Вообще не очевидно. Я там просил привести примеры задач, где именно интенсивный конкурентный доступ к памяти дает явные бенефиты по производительности. Еще раз - задачи массивной обработки в несколько независимых потоков (пожать видео без интенсивной конкуренции за постоянно изменяемые блоки памяти) не интересны - запустить параллельную обработку нескольких логов в попытке дата майнинга аля hadoop - тоже не интересно. Это банальное горизонтальное масштабирование, разбить одну большую задачу на несколько отдельных компьютеров-вычислителей, порезав исходные данные на части, и ребенок справится. Это банальные банальности, и вообще не понятно к чему это все ото выше "поучание".
Есть примеры эффективно распараллеливаемых задач с интенсивным конкурентным доступом к данным?
Нет, вот серьезно, личные примеры-истории успеха применения OpenMP?
В подавляющем большинстве случаев необходимость многопоточки была связана с большими затратам времени на обработку данных.
А можно привести пример таких задач? Перекодирование видео на лету от сразу нескольких потоков, ок, там можно прогрузить множество CPU. Но там синхронизация не нужна, это банальный MPP
А вот так чтоб прям в конкуретный доступ к общей памяти?
Какое нибудь моделирование-оптимизация производственных процессов, или расчет кинематики деформаций при ударе креш-тесте авто (или даже статических прочностых расчетов через МКЭ)? Вот погуглил картинки на предмет Finite Element Method parallel Benchmark - там опять если и есть на что посмотреть, то опять MPP - разбиваем модель на независимые участки и решаем каждую часть условно независимо. Это понятно, но не сильно интересно.
Интересны задачи, где постоянная синхронизация и конкуренция доступа к памяти при многотредности дает реальные и измеримые бенефиты по производительности.
Т.е. прикладник всегда должен видеть узкие места - где минимальными усилиями получить максимальный выигрыш в производительности. По всей задаче в целом.
Так многотредность к производительности обычно никакого отношения не имеет, даже наоборот, может сильно ее просадить (парадокс, но все эти барьеры памяти и атомарные операции в моменте превращают 32 ядра в одно, да еще и без L1/L2 кеша, хоть и краткосрочно).
Автоматический параллелизм и вовсе сдулся, за исключением SIMD операций, вот там да, прогресс прям сильно впечатляет, особенно на каких memcpy(), stnlen(), после ручной оптимизации-имплементации оных на ассемблере.
По всей задаче в целом.
В современном мире многотредность - это чаще всего архитектурный костыль вокруг блокирующего I/O, больше ни для чего она особо и не нужна. А вот переход от многотредно-блокирующего I/O на event based model (epoll) может в разы увеличить пропускную способность, nginx/haproxy/etc это неоднократно уже вроде доказали, в сравнении с каким apache httpd.
А единственный бенефит, который можно реально получить от многоядерности процессоров - это просто разделить задачу по массированной обработке каких гигабайт данных на абсолютно независимые секции, по сути оперировать несколькими компьютерами в одном физическом исполнении. Т.е. вообще без примитивов синхронизации.
Но пытаться выжать из мутексов/семафоров какие-то бенефиты по производительности - это все равно что на хайвее/автобане пытаться ловко-часто расставлять шлагбаумы на каждой полосе, надеясь таким способом разогнать общий поток автомашин.
Выглядит тупиково для автобана, но не для программистов, а почему так - вообще загадка. Вроде инженеры все по образованию, но нет, опять тема этих мутексо-шлагбаумов возникает вновь и вновь.
Еще одна ваша проблема в том, что вы рассуждаете о сферических конях в вакууме. Нужно нехило так пораскинуть мозгами,
Возможно тут и кроется проблема, на самом-то деле. Я кстати изначально только об этом и говорил - что чем мутексы доставать из шкафа - стоит посмотреть на "а можно ли без мутексов? давайте посмотрим как у других"
никак не проливают свет на способы реализации подобных thread-pool-ов без mutex-ов.
Зачем для организации динамически расширяющихся тредпулов вообще нужны мутексы? Чушь какая-то...
А, впрочем, если ты ничего не знаешь про lock-free message passing, и к примеру про вот этот частный случай https://habr.com/ru/articles/130113/
То наверное да, без мутексов в пуллах потом не обойтись.
Только не надо стенать что это про Java и вообще офтопик. Это про банальный circular lock-free buffer queue, в т.ч. multi-writer/multi-reader, оных вариаций и имплементаций вагон и тележка.
почему вы вообще решили, что речь идет о прикладной разработке?
Потому что в статье описан подход, который применим только к прикладной разработке, т.е. идеалистическая попытка сделать нечто так так, чтоб потом типа не думать. Но для системщиков такой подход попросту не нужен, там все иначе устроено.
Если вы настолько уверены, что известные вам принципы работы СУБД
Иногда все-же лучше жевать, чем говорить? При чем тут принципы БД офтопик? С какой стати они вообще офтопик, если там все очень плотно на конкуретном доступе и реализовано?
Или серверы БД не на цифровых компьютерах организованы? Наверное на аналоговых? Оно конечно понятно, что не хочется лишний раз думать и изучать как оно в других областях организовано, но бегать с флагом и кричать "изыди, скучный, ты офтопик, не стенай тут со своими примитивными базами, не мешай умным людям обсуждать всякое" - это как-то... слишком по-детски.
(*) В C++ за счет отсутствия сборщика мусора и из-за отсутствия Rust-овского borrow checker-а проблем с конкурентностью больше. Например, реализация персистентных структур данных (в смысле работ Окасаки, а не в смысле сохранения значений во внешней памяти) из-за отсутствия GC более геморойна.
Вот и у меня создалось впечатление, что каждый пытается говорить о своем, о наболевшим. Но может вернемся от диагностической медицины к битам-байтам?
На чем там остановились? Что мутексы это круто и они очень хорошие и они всегда нужны? Ок, эту мысль зафиксировали. Есть еще что-то сказать, так, чтоб с элементом новизны и оригинальности? Вот про RCU мне понравилось - за столько лет опыта я ни разу про нее не слышал и даже статью в Википедии ранее не читал, и реально сам сильно удивился, почему так, прям очень давно такого не было.
И к чему это было сказано? Там куча "умных" слов про одно и то-же, когда вместо INSERT/UPDATE в базу данных всегда идет только INSERT, на каждое изменение. Тоже механизм обеспечения конкурентной согласованности. В разное время назывался своими именами. А суть всегда одна - на каждый чих вставляем в базу новый object state, целиком. Можно в базу, вставлять, можно в какой application offheap.
Техника тоже приехала из 70-х, широко популярна в узких кругах, а из разработчиков про нее знает от силы 5%, ибо неканонично. В результате ее и назвали N именами - проще было новое название выдумать, чем узнать у других как эта джедайская техника тут правильно называется. И с RCU аналогично.
и там на первых листах про то, что вот раньше трава была зеленее и в целом в 1975 все об... стояло не то что сейчас.
Как по мне - это лишь одна из многих lock-free техник, производная от CAS. В основе подхода - шарить только то, что read/only, и сериализовать (до одного писателя) все, что read/write, и кто против? И это теперь всегда обязательно надо называть RCU, а не MVCC? ок, пусть будет RCU, возьмем за основу термин, широко известный в узких кругах ОС строителей, чтоб никому не было так обидно.
Больше претензий к терминологии-аббревиатурам никаких нет? А там еще TBCC есть, timestamp based concurency control, она-же insert only database, она же Log Database, она же EventSourcing, она-же ... как не обидно принято сейчас называть вот это вот все?
А вот конкретно RCU или STM в ваших стенаниях что-то не замечал.
Ну там и про CoW тоже ничего не было, page faults, madvise(), offset pointers и что теперь? Общий посыл был и так понятен - мутексы и в целом примитивы синхронизации это точно не то, что нужно для прикладной (не системно-библиотечной) разработки общего назначения. Прикладник должен писать предельно простой линейный код без оглядки на конкурентные примитивы, среда (фреймворк) должна обеспечивать конкурентную корректность из коробки.
Ибо постоянно изменяющиеся бизнес-требования никак не способствуют поддержке корректной работы многотредного кода, тут никакой Америки нет, и так все всем давно известно.
Но если это не так, и при реализации бизнес задач (а судя по примерам из статьи речь идет о них) от прикладника требуется знать и уметь про барьеры памяти и мутексы - то скорее всего просто базовый фреймворк и/или требования в задаче неадекватны (кривая архитектура).
А вот для системно-библиотечного уровня вопрос правильно организованной конкурентности и так более менее индустрией решен - берем исходники PostgreSQL, Linux Kernel или т.д. чего иного более менее успешного и стабильного, и изучаем оные подходы до полного прозрения и способности скопировать по образу подобию, ничего нового там не придумать, все было придумано еще в 70-х.
Т.е. если данную статью читают разработчики библиотек, которым нужна работа с mutex-ами, то ваше мнение, как мнение юзера, они могут смело проигнорировать. Так ведь получается?
Есть инженер-проектировщик из НИИ, а есть инженер-мастер из сборочного цеха. Это разные уровни. Один должен уметь траектории ракет на гиперзвуке рассчитывать, а второй - пояснить рабочему как правильно гайки крутить, чтоб резьбу не сорвать.
Должны ли они учитывать мнение друг друга? Конечно должны.
А что не должны? Ну наверное инженер из НИИ, выдавая инженеру из сборочного цеха чертежи на болты и гайки для организации сборки - не должен требовать от последнего уметь в сопромат МКЭ и прочую динамику жидких сред системами дифференциальных уравнений второго порядка методом Рунге-Кутта.
Он должен дать что-то попроще, вроде инструкций - "сталь 20ХНА, значит закручиваем динамометрическим ключом, усилие - 5 ньютон-метр".
Вот так и тут. Есть прикладные программисты, которые бухгалтерии пишут, а есть те, кто серверы баз данных разрабатывают. Это разные миры. Требовать от 1С-ника уметь в барьеры и семафоры - это так себе затея. Впрочем, редко какая библиотека такое требует, мир не настолько безумен.
Другое дело что какой вчерашний 1Сник может начитаться ненужных книжек про Concurency in Action и давай себе чудить что-то эдакое на своих вебсервисах для заказа пиццы на такси.
Еще можно было бы понять, если бы мутексам в противовес приводили RCU или software transactional memory.
Так это и предлагали. Прям именно это.
Но высокопарные рассуждения про MDBX/SQL...
Что это? Опять у кого-то пригорело? Нужно срочно извиниться, чтоб не заминусовали карму или что?
, а при реализации вот этой самой MDBX (т.е. в коде MDBX) можно долбиться в семафоры и атомики
При реализации самой библиотеки - ее, библиотеки, автору - наверняка нужно, но это его проблемы. А вот мне, пользователю библиотеки, при ее использовании - уже нет, я как юзер про мутексы-семафоры могу вообще забыть, да и вообще в них и вовсе не уметь (тем более очень мало кто умеет, это даже нормально).
Через телефон (смартфон). Которые есть у абсолютно всех.
И Linux и Windows умеют отличать обработчики событий и по нажатию, по отпусканию. Но вот в Linux разработчики именно переключателя раскладки почему-то уперлись в нажатие. Почему так, не вникал, это уже годами не лечится.
Но и в Windows тоже было не все ок с этим. Мне в бытность пришлось в VSCode принудительно переназначить все Ctrl+Shift+<чтототам>, потому что случались ложные срабатывания переключателя раскладки. Т.е. собирался что-то там сделать, нажал Ctrl+Shift, в последний момент передумал, отпустил - бац, и уже пишешь код кириллицей.
Не то что часто такое происходило, но тоже раздражало. Впрочем, само понятие шотката на три кнопки - уже клинический случай, их все равно нужно было переназначить.
Слишком сильно сильный грохот по ночам :) И не сильно совместимо со слепой печатью. Одно дело оттопыренным мизинцем нажимать CapsLock, другое дело - этим левым мизинцем попытаться попасть в Win/Cmd этот (а он в три раза меньше Caps), а потом еще и в Space большим пальцем.
Ctrl+Shift и то были удобнее - их можно было сразу две одним мизинцем нажать (именно по этой причине выбешивала "стандартная" двухпацльцевая растопырка Alt-Shift, в которую нужно было целиться двумя пальцами, т.е. сбивать режим слепой печати).
Нет, это ментальная ловушка как в анекдоте про апельсин, клетку и обезьян, брандспойт и "так так принято".
Т.е. любой ценой достичь того, к чему привык в Windows. Но это все равно что ходить шатать трубу на тему "а чего это у вас тут C: D: E: нет, и вообще каталоги через /, а не через \, срочно, срочно все пропатчить!"
Не надо так делать. Нужно просто расслабиться, пересесть на CapsLock как переключатель раскладки клавиатуры - и через пару недель "стандартные" виндовые Alt+Shift и Ctrl+Shift будут выбешивать в разы сильнее, чем CMD.EXE после bash.
Хотя случаи бывают разные. Возможно кто-то карьеру на CMD.EXE/PowerShell построил и подобный аргумент не оценит.
Да, вот именно, что не принципиально. Но есть вопрос удобства.
Теперь задаемся вопросом - а почему нужно переключать двухклавишной комбинацией? Кто решил что это удобно?
Ctrl+Shift, Alt+Shift, Win+Space - вот кто именно придумал подобные способы?
Есть подозрение, что это были те, кто 99.999% времени сидит на английской раскладке, ничем иным такое иезуитство не объяснить.
Дальше больше - Ок, мы осознали, что переключать можно было бы и одной клавишей, мизинцем, а не принудительной двухпальцевой раскорячкой.
Теперь идем по клавиатуре и смотрим "незадействованные" кандидаты.
Win/Meta занята. Есть еще странная кнопка "меню" справа от правой Win/Meta. Но она есть не на всех клавиатурах.
ScrollLock еще, но до нее тянуться очень долго. И она мелкая, хрен попадешь. А на некоторых ноутбуках отсуствует.
Получается единственно реально общедоступной и свободной от полезных функций кнопкой является CapsLock.
И физически CapsLock выглядит хорошо. Он большой, удобно лежит под левым мизинцем.
Применяется? В обычной жизни "применяется" лишь для режима "балин, опять случайно включился, забой, забой, забой, тааак... выключаем. Выключился? Балин, еще раз".
Потому ей реально никто и не пользуется. ДАЖЕ ЕСЛИ НАДО ПОКРИЧАТЬ - то это делается комбинацией "задавили мизинцем Shift и печатаем остальными пальцами"
Потому просто переделываем CapsLock на переключатель раскладки и радуемся жизни. В линуксе это очень просто (какой-то gnone-tweak-tool, не помню уже, делается один раз при установке, элементарно гуглится по "centos|ubuntu|arch switch caps layout").
Может быть те люди, которые 99.999% времени сидят на английской раскладке - догадаются сделать это по дефолту, но сомнительно.
Скорее всего они у себя там в US КРИЧАТ через CapsLock, и им это прям очень важно, поди пойми этих американцев.
P.S. А еще можно было бы ножную педаль придумать, как на рояле. Но готовых вариантов почему-то никто не продает.
Поздравляю парни, да вы открыли понятие DSL!
А любой DSL можно на любом другом языке реализовать. Хоть на Python, хоть на C++, да хоть на JSON.
И это не проблема "базового" языка, это проблема продуманности (или, что чаще встречается - непродуманности и/или излишней абстрактности-заумности) предлагаемых API и прочих специфичных задаче сниппетов и структур.
Применительно к С++ это и вовсе означает очевидное - пора выбросить многовековое нагромождение шаблонных несуразиц по имени STL как "стандарт", которое задает тон всем остальным библиотекам, и заменить чем-то более простым, понятным, адекватным и современным.
Взяв лучшее от "C++ вытеснителей".
И дело пойдет. Но никто пока не решается.
Тема Ctrl+Shift против Caps уже обсуждалась сотни раз даже на хабре. Не надо в Линуксе Ctrl+Shift, после недели на Caps гуглится Recaps и наступает всеобщее счаcтье и понимание, что это в Windows все изначально не так было сделано.
Аналогично порвали десятки баянов на теме KDE vs XFCE vs Gnome (который плагинами кстати тоже можно довести до внешнего вида Win10 https://extensions.gnome.org/#sort=downloads Dash to Panel, Arc menu и т.д.).
Новизна статьи поста вообще в чем? Что в Linux можно работать не только через putty? А то блин мужики и не знали :)
Трудно сказать, ни разу ее в деле нигде даже на стенде не видел, только в статьях и книжках. Где она вообще применяется? В автомобилях на панелях можно увидеть Android, Windows (иногда, на старых авто особенно). А в микроконтроллеры она не влезет.
Актуальна в режиме доживания в корпоративе, где она в основном и применялась. Проекты по миграции на RHEL или на SLES уже много лет являются трендом. Даже сам Oracle активно форсирует свой OEL как замену. SPARC это уже больше экзотика, последнее что там было новационное - это нативная поддержка Oracle Database арифметики (вариации BCD NUMBERS), и то, Oracle проще будет с ARM договориться (туда все и идет).
Playstation это прям сильно нишевое. Игроделы ЕМНИП работают и вовсе на платформо-независимых абстракциях. А MacOS актуальна разве как запускалка AutoCAD и MS Office, которые почему-то до сих пор под Linux не портировали. Ну и Dockerа. Хотя безусловно есть любители разработки и чисто под MacOS, но POSIXом там явно не ограничивается, мягко говоря.
Насколько я помню даже Oracle не получилось Java APIs в суде отстоять, хотя денег туда в суды вбухали порядочно. А что, действительно ходят и пальчиком грозят, что использовать Linux APIs никак нельзя? Я как-то краем глаза видел, что во FreeBSD пытались нативно Linux ELFы запускать, кажется вот про это https://docs.freebsd.org/en/articles/linux-emulation/
Никто вроде не приходил трубу шатать, возможно я пропустил что-то.
А что так? Личная боль в виде растраченных инвестиций в Solaris? Я вот сейчас уже даже и не припомню каких-то особо уникально полезных APIs в Solaris, аналогов которых в Linux не было (про обратное сказать не получится). Но они точно были, миграции проходили не в режиме перекомпилировали, подкинув врапперов и ifdefов и поехали.
Ок, вот сейчас я честно просмотрел и статьи выборочно, и restino, и даже sobjectizer ...
Искренне прошу прощения, действительно, нельзя спорить с таким сильным и многоопытным программистом :)
Так с этого и надо было сразу начинать (сразу и закончить), а не пытаться "уровни" подготовки и прочие личностные оценочные суждения по щекам размазывать, право.
Я так понимаю примеров эффективного решения задач с высококонкурентным параллелизмом на тредах (а не банальных MPP с тотальной изоляцией workerов и их окружения) мы не дождемся?
Давно-не подавно. Это все не интересно. Мне интересен лишь один простой вопрос - насколько реально нужны именно треды с мутексами и можно ли их заменить на взаимно изолированные процессы в один поток с message passing, как универсальную архитектуру в общем случае.
Почему интересно - чисто как мотивация упростить базовые APIs в фреймворке, выбросив примитивы многотредовой синхронизации (начиная с pthread) вообще как понятие, ограничившись лишь CAS (а то и вовсе memory barrier) на inter-process message passing.
Сказки про то, кто там теме и не в теме и прочий подобный детский садик - это не интересно. Просто хочется услышать реальный внятный пример, дескать а вот тут треды и мутексы нам были очень нужны, без них вообще никак, прям беда беда без них, огорчение.
Уже несколько лет пытаюсь найти подобные задачи, ни разу не встречались (а вот эффективные MPP с тотальной изоляцией исполнителей встречались постоянно, тут и спорить нечего)
Чем минусы ставить - читать стоит сначала. Там было сказано - обычно не имеет. Имелось в виду тех самых задачах concurrent computing и blocking I/O.
Вообще не очевидно. Я там просил привести примеры задач, где именно интенсивный конкурентный доступ к памяти дает явные бенефиты по производительности. Еще раз - задачи массивной обработки в несколько независимых потоков (пожать видео без интенсивной конкуренции за постоянно изменяемые блоки памяти) не интересны - запустить параллельную обработку нескольких логов в попытке дата майнинга аля hadoop - тоже не интересно. Это банальное горизонтальное масштабирование, разбить одну большую задачу на несколько отдельных компьютеров-вычислителей, порезав исходные данные на части, и ребенок справится. Это банальные банальности, и вообще не понятно к чему это все ото выше "поучание".
Есть примеры эффективно распараллеливаемых задач с интенсивным конкурентным доступом к данным?
Нет, вот серьезно, личные примеры-истории успеха применения OpenMP?
А можно привести пример таких задач? Перекодирование видео на лету от сразу нескольких потоков, ок, там можно прогрузить множество CPU. Но там синхронизация не нужна, это банальный MPP
А вот так чтоб прям в конкуретный доступ к общей памяти?
Какое нибудь моделирование-оптимизация производственных процессов, или расчет кинематики деформаций при ударе креш-тесте авто (или даже статических прочностых расчетов через МКЭ)?
Вот погуглил картинки на предмет Finite Element Method parallel Benchmark - там опять если и есть на что посмотреть, то опять MPP - разбиваем модель на независимые участки и решаем каждую часть условно независимо. Это понятно, но не сильно интересно.
Интересны задачи, где постоянная синхронизация и конкуренция доступа к памяти при многотредности дает реальные и измеримые бенефиты по производительности.
Так многотредность к производительности обычно никакого отношения не имеет, даже наоборот, может сильно ее просадить (парадокс, но все эти барьеры памяти и атомарные операции в моменте превращают 32 ядра в одно, да еще и без L1/L2 кеша, хоть и краткосрочно).
Автоматический параллелизм и вовсе сдулся, за исключением SIMD операций, вот там да, прогресс прям сильно впечатляет, особенно на каких memcpy(), stnlen(), после ручной оптимизации-имплементации оных на ассемблере.
В современном мире многотредность - это чаще всего архитектурный костыль вокруг блокирующего I/O, больше ни для чего она особо и не нужна. А вот переход от многотредно-блокирующего I/O на event based model (epoll) может в разы увеличить пропускную способность, nginx/haproxy/etc это неоднократно уже вроде доказали, в сравнении с каким apache httpd.
А единственный бенефит, который можно реально получить от многоядерности процессоров - это просто разделить задачу по массированной обработке каких гигабайт данных на абсолютно независимые секции, по сути оперировать несколькими компьютерами в одном физическом исполнении. Т.е. вообще без примитивов синхронизации.
Но пытаться выжать из мутексов/семафоров какие-то бенефиты по производительности - это все равно что на хайвее/автобане пытаться ловко-часто расставлять шлагбаумы на каждой полосе, надеясь таким способом разогнать общий поток автомашин.
Выглядит тупиково для автобана, но не для программистов, а почему так - вообще загадка. Вроде инженеры все по образованию, но нет, опять тема этих мутексо-шлагбаумов возникает вновь и вновь.
Возможно тут и кроется проблема, на самом-то деле. Я кстати изначально только об этом и говорил - что чем мутексы доставать из шкафа - стоит посмотреть на "а можно ли без мутексов? давайте посмотрим как у других"
Зачем для организации динамически расширяющихся тредпулов вообще нужны мутексы? Чушь какая-то...
А, впрочем, если ты ничего не знаешь про lock-free message passing, и к примеру про вот этот частный случай https://habr.com/ru/articles/130113/
То наверное да, без мутексов в пуллах потом не обойтись.
Только не надо стенать что это про Java и вообще офтопик. Это про банальный circular lock-free buffer queue, в т.ч. multi-writer/multi-reader, оных вариаций и имплементаций вагон и тележка.
Потому что в статье описан подход, который применим только к прикладной разработке, т.е. идеалистическая попытка сделать нечто так так, чтоб потом типа не думать. Но для системщиков такой подход попросту не нужен, там все иначе устроено.
Иногда все-же лучше жевать, чем говорить? При чем тут принципы БД офтопик? С какой стати они вообще офтопик, если там все очень плотно на конкуретном доступе и реализовано?
Или серверы БД не на цифровых компьютерах организованы? Наверное на аналоговых? Оно конечно понятно, что не хочется лишний раз думать и изучать как оно в других областях организовано, но бегать с флагом и кричать "изыди, скучный, ты офтопик, не стенай тут со своими примитивными базами, не мешай умным людям обсуждать всякое" - это как-то... слишком по-детски.
Вот и у меня создалось впечатление, что каждый пытается говорить о своем, о наболевшим. Но может вернемся от диагностической медицины к битам-байтам?
На чем там остановились? Что мутексы это круто и они очень хорошие и они всегда нужны? Ок, эту мысль зафиксировали. Есть еще что-то сказать, так, чтоб с элементом новизны и оригинальности?
Вот про RCU мне понравилось - за столько лет опыта я ни разу про нее не слышал и даже статью в Википедии ранее не читал, и реально сам сильно удивился, почему так, прям очень давно такого не было.
Есть еще интересные-нескучные аббревиатуры?
И к чему это было сказано? Там куча "умных" слов про одно и то-же, когда вместо INSERT/UPDATE в базу данных всегда идет только INSERT, на каждое изменение. Тоже механизм обеспечения конкурентной согласованности. В разное время назывался своими именами. А суть всегда одна - на каждый чих вставляем в базу новый object state, целиком. Можно в базу, вставлять, можно в какой application offheap.
Техника тоже приехала из 70-х, широко популярна в узких кругах, а из разработчиков про нее знает от силы 5%, ибо неканонично. В результате ее и назвали N именами - проще было новое название выдумать, чем узнать у других как эта джедайская техника тут правильно называется. И с RCU аналогично.
Да хоть BolgenOS. Википедия говорит что там в основе ядра С, на офсайте пишут что С и С++, качать проверять это все совсем не хочется.
Ну конкретно по RCU -
https://en.wikipedia.org/wiki/Read-copy-update
упоминается VM/XA, и в ссылках переход на статью
http://www.rdrop.com/users/paulmck/RCU/RCUdissertation.2004.07.14e1.pdf
и там на первых листах про то, что вот раньше трава была зеленее и в целом в 1975 все об... стояло не то что сейчас.
Как по мне - это лишь одна из многих lock-free техник, производная от CAS. В основе подхода - шарить только то, что read/only, и сериализовать (до одного писателя) все, что read/write, и кто против? И это теперь всегда обязательно надо называть RCU, а не MVCC? ок, пусть будет RCU, возьмем за основу термин, широко известный в узких кругах ОС строителей, чтоб никому не было так обидно.
Больше претензий к терминологии-аббревиатурам никаких нет? А там еще TBCC есть, timestamp based concurency control, она-же insert only database, она же Log Database, она же EventSourcing, она-же ... как не обидно принято сейчас называть вот это вот все?
Ну там и про CoW тоже ничего не было, page faults, madvise(), offset pointers и что теперь? Общий посыл был и так понятен - мутексы и в целом примитивы синхронизации это точно не то, что нужно для прикладной (не системно-библиотечной) разработки общего назначения. Прикладник должен писать предельно простой линейный код без оглядки на конкурентные примитивы, среда (фреймворк) должна обеспечивать конкурентную корректность из коробки.
Ибо постоянно изменяющиеся бизнес-требования никак не способствуют поддержке корректной работы многотредного кода, тут никакой Америки нет, и так все всем давно известно.
Но если это не так, и при реализации бизнес задач (а судя по примерам из статьи речь идет о них) от прикладника требуется знать и уметь про барьеры памяти и мутексы - то скорее всего просто базовый фреймворк и/или требования в задаче неадекватны (кривая архитектура).
А вот для системно-библиотечного уровня вопрос правильно организованной конкурентности и так более менее индустрией решен - берем исходники PostgreSQL, Linux Kernel или т.д. чего иного более менее успешного и стабильного, и изучаем оные подходы до полного прозрения и способности скопировать по образу подобию, ничего нового там не придумать, все было придумано еще в 70-х.
Есть инженер-проектировщик из НИИ, а есть инженер-мастер из сборочного цеха. Это разные уровни. Один должен уметь траектории ракет на гиперзвуке рассчитывать, а второй - пояснить рабочему как правильно гайки крутить, чтоб резьбу не сорвать.
Должны ли они учитывать мнение друг друга? Конечно должны.
А что не должны? Ну наверное инженер из НИИ, выдавая инженеру из сборочного цеха чертежи на болты и гайки для организации сборки - не должен требовать от последнего уметь в сопромат МКЭ и прочую динамику жидких сред системами дифференциальных уравнений второго порядка методом Рунге-Кутта.
Он должен дать что-то попроще, вроде инструкций - "сталь 20ХНА, значит закручиваем динамометрическим ключом, усилие - 5 ньютон-метр".
Вот так и тут. Есть прикладные программисты, которые бухгалтерии пишут, а есть те, кто серверы баз данных разрабатывают. Это разные миры. Требовать от 1С-ника уметь в барьеры и семафоры - это так себе затея. Впрочем, редко какая библиотека такое требует, мир не настолько безумен.
Другое дело что какой вчерашний 1Сник может начитаться ненужных книжек про Concurency in Action и давай себе чудить что-то эдакое на своих вебсервисах для заказа пиццы на такси.
Так это и предлагали. Прям именно это.
Что это? Опять у кого-то пригорело? Нужно срочно извиниться, чтоб не заминусовали карму или что?
При реализации самой библиотеки - ее, библиотеки, автору - наверняка нужно, но это его проблемы. А вот мне, пользователю библиотеки, при ее использовании - уже нет, я как юзер про мутексы-семафоры могу вообще забыть, да и вообще в них и вовсе не уметь (тем более очень мало кто умеет, это даже нормально).