У нескольких авторов встречал аналогию нервной системы и мышечной. "Мышцы" мозга нужно тренировать точно также, как и обычные. Так же как если два раза за месяц подойти к турникам - не будет прогресса, также и за два посещения психолога. Да, психолог, может написать программу тренировок, и возможно даже качественную. Но это не отменяет того, что кто-то должен эту программу выполнять...
Гордона Ньюфилда читали? У него в соавторстве с Габором Матэ хорошая книга - "Не упускайте своих детей". Ну и видимо есть и другие книги. Проблема, на мой взгляд, действительно есть. Только она намного шире и не понятно - есть ли решение?!
Вы в статье говорите, что ситуации чтения и записи ассиметричны. Это заблуждение, они очень даже симметричны. Просто ваш пример кода неудачный. Он выявляет коллизию только на чтении, а на записи не выявляет. Коллизия есть в обоих случаях в вашем псевдокоде. И на записи и на чтении. Проблема в том что tx_queue_sz читается-модифицируется-записывается с двух мест. Про volatile вам тоже верно сказали. Например в функции main компилятор может оптимизировать код так, что скопирует значение tx_queue_sz или tx_queue_ind в регистр и будет пользоваться регистром совершенно не предполагая о том, что надо обновлять значение из переменной. Особенно, если код обработки прерывания будет в другом модуле трансляции.
Вы тоже заметили эту ошибку! А автор так и не понял, что это ошибка! @vadjuse, обратите внимание, что здесь совершенно справедливо заметили: переменная tx_queue_sz меняется (проходит через процедуру: чтение-модификация-запись) и в основном потоке, и в потоке прерываний. То что ваши примеры не выявляют данную коллизию проблема исключительно ваших примеров. Коллизия есть и она вполне реальная. Довольно легко смоделировать ситуацию, когда ваш код продублирует отправку некоторых байтов. Задача для вас - найти и описать эту ситуацию (ждем правильный ответ)! Спасибо за материал, потренировал свои извилины.
Кстати, есть ситуации когда формально код ревью есть, а фактически его нет. Т.е. код никто серьезно не читает, и все ждут когда кто-нибудь один подтвердит, чтобы потом успокаивать себя тем, что "ну он же посмотрел, значит все ок". Тем временем первый человек из категории тех, которые никогда ничего не находят на код ревью.
Там вроде не нарушены, а просто затронуты. Это чистая логика судопроизводства, все кодексы эту идею повторяют. Суд не может разрешить твои права, не обеспечив тебе право на участие в процессе (в каком-либо виде). Процесс - состязательный.
В общем тут истцы - не прокуратура. И я бы не рассматривал ситуацию как фильмы ужасов, где где главный антагонист всегда без особых хлопот оказывается за спиной у протагониста. Со стороны истца тоже много проблем и сложностей, там ниже кто-то уже указывал.
Если не заявит, то преюдиции не будет. В их же интересах заявить, иначе автор может просто на другой площадке это разместить, и вообще оспорить в рамках отдельного производства, а потом повторно разместить. Хотя могу каких-то ньюансов не знать, уже давно не практикую и тема не совсем моя. Это рассуждения чисто из теории процесса.
Сразу видно опытный человек, а не вот это вот всё (то что выше понаписано)! Пока что самый грамотный комментарий по юридической стороне вопроса, из тех что успел прочитать.
Я думаю его привлекут третьим лицом на стороне ответчика (это стандартная практика), если не соответчиком, суд предложит и вряд ли истец откажется, уж в качестве третьего лица точно.
У них емаил указан в контактах. Направление на него письма, является надлежащими ответом на их письмо (по форме). Содержание тоже адекватное: вы говорите информация недостоверная? - ок, укажите какая, мы исправим (ошибки, действительно, возможны). Но в целом, в суд они все равно могут подать, потому что физически могут и для них это небольшие затраты, а для автора все-таки неприятность и другим наука. Полагаю это будет арбитражный суд, там качественно дела разрешают, спасибо бывшему председателю А.А. Иванову, очень хорошую систему выстроил!
Тоже оценил "элегантность" решения. В dismiss теперь надо передавать параметр! Т.е. это не метод конкретного экрана блокировки или его родителя. Ну и также остался вопрос, с закрытием экрана блокировки PIN/PUK, а кто для него вызвал тогда метод?! Я бы скорее подумал, что все таки dismiss грохал весь стэк. И теперь сделали, чтобы метод грохал не весь стэк а только конкретный экран, который и был разблокирован. В общем медведя на велосипеде с костылем все вспомнили
Сеньор С++ - это самозванец? Любой адекватный собеседующий, понимающий дефицит спецов на рынке, с руками оторвет! Человек готов выучить новый язык, хочет расти и развиваться - просто золотой кадр. У многих в голове засела навязчивая идея - найти серебряную пулю, которая сразу закроет кадровый дефицит, а надо уметь работать с тем что есть на рынке. По моему опыту реально рабочих варианта два: 1) взять и выучить студента; 2) переучить спеца со смежной специальности.
Мне из последнего про операционки, архитектуру и обработку событий понравилась книжка Miro Samek - PSiCC2. Сначала я нашел его сайт (state-machine.com), потом статьи, потом книжку. Сам его фрэймворк мне не оч зашел по различным причинам, но идеи я использую. Его подход к использованию такого инструмента как RTOS мне ближе всего оказался.
Это просто наблюдение из жизни, у нас большая команда разработчиков, но большинство сходу не объяснят наследование приоритетов. Трудно сказать о чем это говорит, ну а RTOS используется потому что есть, "Я человек простой: вижу API - использую". Но про наследование приритетов реально не все вникают, а встретить его на этапе проектирования - вообще редкость, максимум это когда уже решаешь какую-то проблему с отзывчивостью.
В тех проектах где я работал(аю), данная проблема не проявлялась. Но и в целом я не сторонник большого количества задач в системе, где возникает необходимость мьютексов и такие запутанные случаи с ними. Последнее время я предпочитаю сбалансированный подход, стараясь внутри задачи организовать Event Driven архитектуру и минимизируя тем самым количество задач.
Мое личное наблюдение, что далеко не каждый разработчик знает чем отличаются мьютекс и семафор, и уж тем более сможет сходу объяснить зачем нужно наследование приоритетов на классическом примере из трех задач.
В TNeo мне больше понравилось то, что автор покрыл его тестами и внедрил фраймворк Ceedling. Также у него есть несколько статей по проведенным оптимизациям. И отдельно есть статья наподобие вашей про организацию прерываний и стэка прерываний, с особенностями реализации на PIC где нет таких удобств как у Cortex-M3.
Кстати, вот вы упомянули про аж целых два прерывания, а на самом деле нужно только одно и второе во фриртосе используется исключительно для поддержания совместимости с ядрами в которых есть ММU. И в порте для кортекса М3, например, vPortSVCHandler только один раз вызывается при старте планировщика, и более никогда. Они и сами, кстати, тоже самое что и я объясняют. Вообще supervisor call это именно для ММU, ну насколько я в этом для себя разобрался. То что вы смотрите на фриртос это хорошо, но для обобщения лучше иметь больше одного примера. Посмотрите еще на TNeo (это развитие энтузиастом проекта TnKernel).
У нескольких авторов встречал аналогию нервной системы и мышечной. "Мышцы" мозга нужно тренировать точно также, как и обычные. Так же как если два раза за месяц подойти к турникам - не будет прогресса, также и за два посещения психолога. Да, психолог, может написать программу тренировок, и возможно даже качественную. Но это не отменяет того, что кто-то должен эту программу выполнять...
Гордона Ньюфилда читали? У него в соавторстве с Габором Матэ хорошая книга - "Не упускайте своих детей". Ну и видимо есть и другие книги. Проблема, на мой взгляд, действительно есть. Только она намного шире и не понятно - есть ли решение?!
По проблеме с работой по I2C на прерываниях. Вы это на STM32 делали? Случайно не F10x серия?
Вы в статье говорите, что ситуации чтения и записи ассиметричны. Это заблуждение, они очень даже симметричны. Просто ваш пример кода неудачный. Он выявляет коллизию только на чтении, а на записи не выявляет. Коллизия есть в обоих случаях в вашем псевдокоде. И на записи и на чтении. Проблема в том что
tx_queue_szчитается-модифицируется-записывается с двух мест. Проvolatileвам тоже верно сказали. Например в функции main компилятор может оптимизировать код так, что скопирует значениеtx_queue_szилиtx_queue_indв регистр и будет пользоваться регистром совершенно не предполагая о том, что надо обновлять значение из переменной. Особенно, если код обработки прерывания будет в другом модуле трансляции.Вы тоже заметили эту ошибку! А автор так и не понял, что это ошибка! @vadjuse, обратите внимание, что здесь совершенно справедливо заметили: переменная
tx_queue_szменяется (проходит через процедуру: чтение-модификация-запись) и в основном потоке, и в потоке прерываний. То что ваши примеры не выявляют данную коллизию проблема исключительно ваших примеров. Коллизия есть и она вполне реальная. Довольно легко смоделировать ситуацию, когда ваш код продублирует отправку некоторых байтов. Задача для вас - найти и описать эту ситуацию (ждем правильный ответ)! Спасибо за материал, потренировал свои извилины.Кстати, есть ситуации когда формально код ревью есть, а фактически его нет. Т.е. код никто серьезно не читает, и все ждут когда кто-нибудь один подтвердит, чтобы потом успокаивать себя тем, что "ну он же посмотрел, значит все ок". Тем временем первый человек из категории тех, которые никогда ничего не находят на код ревью.
Там вроде не нарушены, а просто затронуты. Это чистая логика судопроизводства, все кодексы эту идею повторяют. Суд не может разрешить твои права, не обеспечив тебе право на участие в процессе (в каком-либо виде). Процесс - состязательный.
В общем тут истцы - не прокуратура. И я бы не рассматривал ситуацию как фильмы ужасов, где где главный антагонист всегда без особых хлопот оказывается за спиной у протагониста. Со стороны истца тоже много проблем и сложностей, там ниже кто-то уже указывал.
Если не заявит, то преюдиции не будет. В их же интересах заявить, иначе автор может просто на другой площадке это разместить, и вообще оспорить в рамках отдельного производства, а потом повторно разместить. Хотя могу каких-то ньюансов не знать, уже давно не практикую и тема не совсем моя. Это рассуждения чисто из теории процесса.
А вот и зря! Арбитражные суды очень качественно работают со времен господина Иванова! На личном опыте неоднократно убеждался!
Сразу видно опытный человек, а не вот это вот всё (то что выше понаписано)! Пока что самый грамотный комментарий по юридической стороне вопроса, из тех что успел прочитать.
Я думаю его привлекут третьим лицом на стороне ответчика (это стандартная практика), если не соответчиком, суд предложит и вряд ли истец откажется, уж в качестве третьего лица точно.
У них емаил указан в контактах. Направление на него письма, является надлежащими ответом на их письмо (по форме). Содержание тоже адекватное: вы говорите информация недостоверная? - ок, укажите какая, мы исправим (ошибки, действительно, возможны). Но в целом, в суд они все равно могут подать, потому что физически могут и для них это небольшие затраты, а для автора все-таки неприятность и другим наука. Полагаю это будет арбитражный суд, там качественно дела разрешают, спасибо бывшему председателю А.А. Иванову, очень хорошую систему выстроил!
Тоже оценил "элегантность" решения. В dismiss теперь надо передавать параметр! Т.е. это не метод конкретного экрана блокировки или его родителя. Ну и также остался вопрос, с закрытием экрана блокировки PIN/PUK, а кто для него вызвал тогда метод?! Я бы скорее подумал, что все таки dismiss грохал весь стэк. И теперь сделали, чтобы метод грохал не весь стэк а только конкретный экран, который и был разблокирован. В общем медведя на велосипеде с костылем все вспомнили
Сеньор С++ - это самозванец? Любой адекватный собеседующий, понимающий дефицит спецов на рынке, с руками оторвет! Человек готов выучить новый язык, хочет расти и развиваться - просто золотой кадр. У многих в голове засела навязчивая идея - найти серебряную пулю, которая сразу закроет кадровый дефицит, а надо уметь работать с тем что есть на рынке. По моему опыту реально рабочих варианта два: 1) взять и выучить студента; 2) переучить спеца со смежной специальности.
Мне из последнего про операционки, архитектуру и обработку событий понравилась книжка Miro Samek - PSiCC2. Сначала я нашел его сайт (state-machine.com), потом статьи, потом книжку. Сам его фрэймворк мне не оч зашел по различным причинам, но идеи я использую. Его подход к использованию такого инструмента как RTOS мне ближе всего оказался.
Придется другие комменты заплюсовать - замолить грехи)))
Это просто наблюдение из жизни, у нас большая команда разработчиков, но большинство сходу не объяснят наследование приоритетов. Трудно сказать о чем это говорит, ну а RTOS используется потому что есть, "Я человек простой: вижу API - использую". Но про наследование приритетов реально не все вникают, а встретить его на этапе проектирования - вообще редкость, максимум это когда уже решаешь какую-то проблему с отзывчивостью.
За ссылки, спасибо, почитаю!
В тех проектах где я работал(аю), данная проблема не проявлялась. Но и в целом я не сторонник большого количества задач в системе, где возникает необходимость мьютексов и такие запутанные случаи с ними. Последнее время я предпочитаю сбалансированный подход, стараясь внутри задачи организовать Event Driven архитектуру и минимизируя тем самым количество задач.
Мое личное наблюдение, что далеко не каждый разработчик знает чем отличаются мьютекс и семафор, и уж тем более сможет сходу объяснить зачем нужно наследование приоритетов на классическом примере из трех задач.
В TNeo мне больше понравилось то, что автор покрыл его тестами и внедрил фраймворк Ceedling. Также у него есть несколько статей по проведенным оптимизациям. И отдельно есть статья наподобие вашей про организацию прерываний и стэка прерываний, с особенностями реализации на PIC где нет таких удобств как у Cortex-M3.
Кстати, вот вы упомянули про аж целых два прерывания, а на самом деле нужно только одно и второе во фриртосе используется исключительно для поддержания совместимости с ядрами в которых есть ММU. И в порте для кортекса М3, например, vPortSVCHandler только один раз вызывается при старте планировщика, и более никогда. Они и сами, кстати, тоже самое что и я объясняют. Вообще supervisor call это именно для ММU, ну насколько я в этом для себя разобрался. То что вы смотрите на фриртос это хорошо, но для обобщения лучше иметь больше одного примера. Посмотрите еще на TNeo (это развитие энтузиастом проекта TnKernel).