Эта ситуация: самолёт ждёт указаний диспетчера, но диспетчер не сможет дать никаких указаний, пока самолёт не сядет, — и есть типичный дедлок.
Кстати, насчет мьютексов и дидлоков. Эта проблема не мьютексов, как объектов, а их архитектуры (или интерфейса использования). Два взаимосвязанных метода (захват и освобождение) получаются не связаны между собой в коде программы.
А вот если бы мьютекс был реализован как объект ООП, тогда такой ситуации возникнуть просто бы не могло, так как сам компилятор стал бы автоматически управлять взаимозависимыми вызовами одного и того же объекта (например за счет применения какого нибудь std::lock_guard).
Так не нужно корявым примером работы с БД аргументировать наличие проблем в ООП. Или используйте атомарный инкремент средствами самой БД или меняйте алгоритм работы класса на многопоточный.
Ведь ни мьютексы, ни ООП тут не причем, так как эти инструменты действительно нужно уметь правильно готовить использовать.
любой, кто раскрыл рот, чтобы сообщить мне, что я просто не умею их готовить ...
Два вызова метода increment из двух разных потоков приведет к тому, что мы дважды вычитаем предыдущее значение из базы, а потом дважды запишем обратно его же, увеличенное на единицу.
Оказывается, у вас проблемы не только с мьютексами, но и с БД
Теперь не даю клиенту долго думать. Показываю материалы, черчу эскиз, обговариваю цену и заключаю договор на месте.
Был у меня подобный производитель. Заказывал кухню и повелся на обещание бесплатного замера, а по факту оказалось, что требуется обязательно заключить договор с предоплатой и только в этом случае замер будет бесплатным.
А отсутствие материалов (вовремя не закупили) или если вас подвел контрагент никоим образом не создает форсмажортных обстоятельств, т.к. все это может и должно вами контролироваться и оцениваться как обычные бизнес-риски.
Послал подальше таких изготовителей с их филькиными форсмажорными обстоятельствами и заказал в другом месте.
По большей части правильно (в том числе и на основе собственного опыта), но не соглашусь с некоторыми очень категоричными утверждениями.
Во первых, любой менеджмент (в том числе и ПМ) обязан контролировать использование ресурсов, т.е. трудозатраты разработчиков. И если он этого не делает или не умеет делать, то это не проблемы разработчиков, а проблемы именно менеджеров, т.к. именно они управляют расстановкой приоритетов по задачам, а тогда как разработчик волен использовать свою сортировку задач (делать то, что ему наиболее интересно, например, изучать новые языки программирования или фреймворки).
Что же касается тестов (пагинация для -1 страницы), то тестировщик совершенно прав. Любой пользовательский ввод не должен полагаться на добросовестность пользователя и должен быть защищен от его злонамеренных действий.
для которых еще нужна обвязка MCU + разъем и обвязка для USB (у самых дешевых микроконтроллеров поддержки USB может и не быть) + обязательно плата (навесным монтажом проводки к ножкам не припаяешь).
В итоге все это выйдет гораздо дороже и сложнее какого нибудь ESP32 с уже рабочим USB и встроенными WiFi и Bluetooth
В пятьсот рублей у меня никак не влезает: IOT модуль + преобразователь питания (12-24В до 5-7В) + токовый шунт 75мВ + 4 резистора для делителей напряжения + датчик температуры ds18b20. Это минимум без платы и без монтажа.
В принципе можно, но итоговая стоимость такого решения будет значительно дороже. Ведь такая батарея довольно дорогая и к ней потребуется отдельный контролер заряда (ведь зарядка UPSа рассчитана обычную АКБ)
И все это никак не убирает изначальную проблему - удаленный контроль состояния АКБ в ИБП.
теперь Нетбинс настроен, но как настроить дебаг пока не понял.
Начиная с NetBeans 22 у него убрали поддержку старых версий плагинов из-за чего приходится пользоваться NetBeans 21 из-за С/С++ плагина с нормальной поддержкой побсов. К сожалению рано или поздно придется придется переходить на что-то другое, так по сравнению с ним, у ligthweight C++ все приходится настраивать руками.
Конечно плохо, но не этим (поток управления в catch явный, а затраты не такие уж и большие по сравнению с чистотой кода и элементарной логикой обработки ошибок с помощью исключений).
Плохо тем, что если исключения в языке есть, то ими можно не пользоваться (из-за якобы неявного потока управления или "больших затрат"), но если их нет, то приходится писать потрянки кода или и вовсе ошибки игнорировать.
Кстати, насчет мьютексов и дидлоков. Эта проблема не мьютексов, как объектов, а их архитектуры (или интерфейса использования). Два взаимосвязанных метода (захват и освобождение) получаются не связаны между собой в коде программы.
А вот если бы мьютекс был реализован как объект ООП, тогда такой ситуации возникнуть просто бы не могло, так как сам компилятор стал бы автоматически управлять взаимозависимыми вызовами одного и того же объекта (например за счет применения какого нибудь std::lock_guard).
Так не нужно корявым примером работы с БД аргументировать наличие проблем в ООП. Или используйте атомарный инкремент средствами самой БД или меняйте алгоритм работы класса на многопоточный.
Ведь ни мьютексы, ни ООП тут не причем, так как эти инструменты действительно нужно уметь правильно
готовитьиспользовать.Оказывается, у вас проблемы не только с мьютексами, но и с БД
Кондиционером с тепловым насосом получается нормально обогреваться до -15С на улице https://habr.com/ru/articles/857436/
Был у меня подобный производитель. Заказывал кухню и повелся на обещание бесплатного замера, а по факту оказалось, что требуется обязательно заключить договор с предоплатой и только в этом случае замер будет бесплатным.
А отсутствие материалов (вовремя не закупили) или если вас подвел контрагент никоим образом не создает форсмажортных обстоятельств, т.к. все это может и должно вами контролироваться и оцениваться как обычные бизнес-риски.
Послал подальше таких изготовителей с их филькиными форсмажорными обстоятельствами и заказал в другом месте.
Для этого кнопка не нужна, а как, зависит от конкретного сайта, например тут на Хабре, это будет https://habr.com/ru/articles/page-1/
По большей части правильно (в том числе и на основе собственного опыта), но не соглашусь с некоторыми очень категоричными утверждениями.
Во первых, любой менеджмент (в том числе и ПМ) обязан контролировать использование ресурсов, т.е. трудозатраты разработчиков. И если он этого не делает или не умеет делать, то это не проблемы разработчиков, а проблемы именно менеджеров, т.к. именно они управляют расстановкой приоритетов по задачам, а тогда как разработчик волен использовать свою сортировку задач (делать то, что ему наиболее интересно, например, изучать новые языки программирования или фреймворки).
Что же касается тестов (пагинация для -1 страницы), то тестировщик совершенно прав. Любой пользовательский ввод не должен полагаться на добросовестность пользователя и должен быть защищен от его злонамеренных действий.
Clang ?
var в java, это фактически auto в C++
Ага, теперь понятно, почему у меня YouTube ролики не показывал, а после выключения и повторного включения блокировщика рекламы опять появились.
Именно контроль тока на шунте. В этом случае можно будет и емкость/заряд подсчитать и ручную корректировку настроить при необходимости.
Для этого нужен контроль входного напряжения, но вот это делать как раз и не хочется.
Беспроводные интерфейсы идут в комплекте, тогда как основной это USB
С точки зрения потери данных, потерь вообще не будет, так как я дома работаю на ноутбуке, только с внешним монитором и клавиатурой.
Тут больше защита от скачков напряжения при продолжении работы при отсутствии питания.
для которых еще нужна обвязка MCU + разъем и обвязка для USB (у самых дешевых микроконтроллеров поддержки USB может и не быть) + обязательно плата (навесным монтажом проводки к ножкам не припаяешь).
В итоге все это выйдет гораздо дороже и сложнее какого нибудь ESP32 с уже рабочим USB и встроенными WiFi и Bluetooth
Кроме "поддержки" еще есть проблема в актуальных данных.
Именно так я и делаю.
В пятьсот рублей у меня никак не влезает: IOT модуль + преобразователь питания (12-24В до 5-7В) + токовый шунт 75мВ + 4 резистора для делителей напряжения + датчик температуры ds18b20. Это минимум без платы и без монтажа.
Согласен, что нормальные ИБП именно так и должны делать.
Вот только где найти такой нормальный и не дорогой ИБП с поддержкой Linux?
В принципе можно, но итоговая стоимость такого решения будет значительно дороже. Ведь такая батарея довольно дорогая и к ней потребуется отдельный контролер заряда (ведь зарядка UPSа рассчитана обычную АКБ)
И все это никак не убирает изначальную проблему - удаленный контроль состояния АКБ в ИБП.
Начиная с NetBeans 22 у него убрали поддержку старых версий плагинов из-за чего приходится пользоваться NetBeans 21 из-за С/С++ плагина с нормальной поддержкой побсов. К сожалению рано или поздно придется придется переходить на что-то другое, так по сравнению с ним, у ligthweight C++ все приходится настраивать руками.
Конечно плохо, но не этим (поток управления в catch явный, а затраты не такие уж и большие по сравнению с чистотой кода и элементарной логикой обработки ошибок с помощью исключений).
Плохо тем, что если исключения в языке есть, то ими можно не пользоваться (из-за якобы неявного потока управления или "больших затрат"), но если их нет, то приходится писать потрянки кода или и вовсе ошибки игнорировать.