Чтобы понять "чудо" это или "блин", нужно разобраться, что при этом "моделится" в SimInTech - сам двигатель или математическая модель этого двигателя (формула/формулы).
иметь модели (в SimInTech) : резистора, конденсатора, источника.
соединить эти модели в соответствии с принципиальной схемой
3) сравнить: результаты аналитического расчета, результаты моделирования в SimIntech, результаты работы реальной схемы.
Если все совпадет, то тогда можно считать тест пройденным. Этого из статьи, насколько я понимаю, не видно. Верить же просто словам - сложно. Хотелось бы убедиться лично ;).
А посему 1) приведите принципиальную схему теста 2) приведите ссылку, чтобы скачать "тестовый проект" из статьи?
Про класс CFDelay. См. заголовок и реализацию - FDelay.h, FDelay.cpp. Как пользоваться - методы FCreateParDelay(), FIsActiveParDelay() для параллельной задержки и FCreateDelay(int nDelay) - для вложенной Они в классе LFsaAppl (lfsaappl.h, lfsaappl.cpp).
Но есть нюанс, который, возможно, влияет. На ESP32 - без пользовательских библиотек, в Qt - с библиотеками.
Извиняйте - оговорился. Кстати, когда писал, то помню был какой-то "дискомфорт", но не стал заморачиваться... :)
По поводу FDelay.h. Конечно, на гите должно все быть, если интересует. Там все до безобразия просто. Это обычный автомат, считающий такты. В одной ситуации от вызывается подобно подпрограмме, как вложенный автомат, в другой - на его базе создается процесс.
Но вот с "включением" вдруг вылезла проблема. До этого я постоянно пользовался подобной задержкой во всех ее вариантах. Но тут, как говорится: "Не было такого ни когда, а тут - опять!"
Вот про эти "грабли" и приходится разъяснять всяким разным из "ясельных групп". А то, блин, разобьют носы на всяких там качельках, а потом "плачутся" про всякие "пот, боль и кровь"... :)
Читаете внимательно. В режиме Debug программа работала, т.е. ошибки нет и не было. Тут если и есть ошибка, то только не моя.
Кстати про ошибки. Вот сейчас бился над одной :)
Пишу продолжение статьи и делаю таймерную задержку. У меня есть вложенный автомат - CFDelay. Все, вроде, работало и вдруг - перестает. Запускаешь - глюк. Лопачу, сравниваю код - все, вроде, ОК. Натыкаюсь что в одном варианте - работает, в другом - нет. Варианты немного отличаются, но только не в логике. Но ошибка-то есть! Короче.
Вот только выяснил. Проблема в строке:
#include "./LSYSLIB/FDelay.h"
Вставлена - работает. Нет ее - глюк!!! Компиляция - на ура! Запуск - глюк! Сейчас, кода немного подправил вызов заголовков все работает. Но... что было не так-то!?
Сделать-то сделал, но ощущение "костыля" как-то не уходит.... :(
"Тяжела и неказиста жизнь простого программиста" :)
Обычно любому наблюдаемому и воспроизводимому феномену находится рациональное объяснение.
Правильно. Что-то подобное подозревал и я. Потому и начал "копать" цикл. И результат можно именно этим и объяснить, т.е. какой-то не очень корректной (для потоков, конечно) оптимизацией. Но выяснять до конца тоже не очень большой смысл.По крайней мере для меня. Но в целом Вы все объяснили достаточно достоверно. Как бы ДНК оно и есть ДНК. Пусть оно таким и остается :) Хотя, конечно, такой опыт тоже нужен. Но это уже и есть ... "кровопускание" :(
"Обычно когда демонстрируют состояние гонки в многопоточке, то пишут простое как пять копеек консольное приложение"
Дело, конечно, давнее, но обычно я так и делаю... Хотя по поводу того случая так не могу утверждать точно...
Но тогда проблема была совершенно в другом, т.е. совсем не в гонках и счетчике. На это было наплевать... ;)
Проблема была в том, что в режиме Debug работал проект без проблем, а в режиме Release вылетал напрочь.Переходишь в Debug - работает, Release - глюк! Стал менять конструкцию цикла в потоке и в какой-то момент все заработало. Т.е. ошибка ушла, словно и не было. И для меня это осталось загадкой до сих пор. Но в статье все это описано подробно.
Но "мужики-то знают" - "Всё начинается с любви… ". В нашем случае - с любви к математике. Она формализует те термины, вокруг которых ведутся все споры. С человеком, которые этого не понимает, разговаривать те то, что сложно - невозможно, т.к. языки общения разные.
Но когда "нащупаешь" истоки, то все становится сразу все ясно. Например, термины "параллелизм" или "скорость" или ... "асинхронность". Вы даже написали статью на эту тему - асинхронности. Но поскольку не задались с определением асинхронности, то получилось, может, и интересно, но как-то сумбурно и все свалилось в одну кучу ;) Это, конечно, мой взгляд, но... подобные статьи я могу читать только "по диагонали". Может и интересно, но вычленить суть довольно сложно. Хотя, казалось бы, темы-то общие.
Так и про "задержку". Я привел ее формальную модель. Математически строгую. Она объясняет, что такое задержка, какие они бывают и т.д. и т.п. Понимаете ли Вы, что такое "задержка". Какова ее роль вообще, а не только в программировании. Судя по комменту - есть определенные сомнения.
Вот как-то так. Начинать надо с "любви" (математики, конечно) :) И тогда, возможно, не придется "мучиться с многопоточностью".
Совсем не так. Создание еще одного детерминированного автомата для ввода, скажем, символа на вход текущего автомата на не разрушает детерминированность текущего автомата. Причем даже если автомат ввода работает асинхронно текущему автомату. Но если Вы такой эстет и хотите сохранить детерминированность поведения системы тек.автомат+автомат ввода то синхронизируйте их работу в едином времени. Делов-то, как говорится ;)
Вы опять неправильно поняли. Мы можем детерминированным образом перейти от любой МТ к ее параллельной версии. По сути МТ это уже автомат (ее управление). Используя алгебру автоматов, можно любой одиночный автомат разложить на множество параллельных автоматов по операции умножения. Вот и все. И, кстати, это тоже будет детерминированная система - сеть автоматов. Ни какого недетерминизма нет и в помине.
А где в статье про параллельное программирование?
Чтобы понять "чудо" это или "блин", нужно разобраться, что при этом "моделится" в SimInTech - сам двигатель или математическая модель этого двигателя (формула/формулы).
Но мне почему-то хочется проверить "эталонный пример" из данной статье. А если легко, то повторюсь, перефразируя известное: "Хочу схему и проект" :)
Очень правильный вопрос! Хотелось бы подробней.
1) нарисуйте принципиальную схему "теста".
2) и хотелось бы иметь следующую проверку:
иметь модели (в SimInTech) : резистора, конденсатора, источника.
соединить эти модели в соответствии с принципиальной схемой
3) сравнить: результаты аналитического расчета, результаты моделирования в SimIntech, результаты работы реальной схемы.
Если все совпадет, то тогда можно считать тест пройденным. Этого из статьи, насколько я понимаю, не видно. Верить же просто словам - сложно. Хотелось бы убедиться лично ;).
А посему 1) приведите принципиальную схему теста 2) приведите ссылку, чтобы скачать "тестовый проект" из статьи?
Сейчас мы их "докачаем" ;). Смотрите мою статью. Там в конце ссылка на гит.
Про класс CFDelay. См. заголовок и реализацию - FDelay.h, FDelay.cpp. Как пользоваться - методы FCreateParDelay(), FIsActiveParDelay() для параллельной задержки и FCreateDelay(int nDelay) - для вложенной Они в классе LFsaAppl (lfsaappl.h, lfsaappl.cpp).
Но есть нюанс, который, возможно, влияет. На ESP32 - без пользовательских библиотек, в Qt - с библиотеками.
Ну, все знать невозможно. А тут явно не моя "засада".
Извиняйте - оговорился. Кстати, когда писал, то помню был какой-то "дискомфорт", но не стал заморачиваться... :)
По поводу FDelay.h. Конечно, на гите должно все быть, если интересует. Там все до безобразия просто. Это обычный автомат, считающий такты. В одной ситуации от вызывается подобно подпрограмме, как вложенный автомат, в другой - на его базе создается процесс.
Но вот с "включением" вдруг вылезла проблема. До этого я постоянно пользовался подобной задержкой во всех ее вариантах. Но тут, как говорится: "Не было такого ни когда, а тут - опять!"
Вот про эти "грабли" и приходится разъяснять всяким разным из "ясельных групп". А то, блин, разобьют носы на всяких там качельках, а потом "плачутся" про всякие "пот, боль и кровь"... :)
Компилятор - не видит?! Да какое мне до этого дело. Если программист сказал stop, значит, - стоп! Больно умный! :)
Читаете внимательно. В режиме Debug программа работала, т.е. ошибки нет и не было. Тут если и есть ошибка, то только не моя.
Кстати про ошибки. Вот сейчас бился над одной :)
Пишу продолжение статьи и делаю таймерную задержку. У меня есть вложенный автомат - CFDelay. Все, вроде, работало и вдруг - перестает. Запускаешь - глюк. Лопачу, сравниваю код - все, вроде, ОК. Натыкаюсь что в одном варианте - работает, в другом - нет. Варианты немного отличаются, но только не в логике. Но ошибка-то есть! Короче.
Вот только выяснил. Проблема в строке:
#include "./LSYSLIB/FDelay.h"
Вставлена - работает. Нет ее - глюк!!! Компиляция - на ура! Запуск - глюк! Сейчас, кода немного подправил вызов заголовков все работает. Но... что было не так-то!?
Сделать-то сделал, но ощущение "костыля" как-то не уходит.... :(
"Тяжела и неказиста жизнь простого программиста" :)
Где тут бесконечный цикл? Он был бы в случае: while(true){}. А тут нормальный цикл только с пустым телом цикла.
Правильно. Что-то подобное подозревал и я. Потому и начал "копать" цикл. И результат можно именно этим и объяснить, т.е. какой-то не очень корректной (для потоков, конечно) оптимизацией. Но выяснять до конца тоже не очень большой смысл.По крайней мере для меня. Но в целом Вы все объяснили достаточно достоверно. Как бы ДНК оно и есть ДНК. Пусть оно таким и остается :) Хотя, конечно, такой опыт тоже нужен. Но это уже и есть ... "кровопускание" :(
"Обычно когда демонстрируют состояние гонки в многопоточке, то пишут простое как пять копеек консольное приложение"
Дело, конечно, давнее, но обычно я так и делаю... Хотя по поводу того случая так не могу утверждать точно...
Но тогда проблема была совершенно в другом, т.е. совсем не в гонках и счетчике. На это было наплевать... ;)
Проблема была в том, что в режиме Debug работал проект без проблем, а в режиме Release вылетал напрочь.Переходишь в Debug - работает, Release - глюк! Стал менять конструкцию цикла в потоке и в какой-то момент все заработало. Т.е. ошибка ушла, словно и не было. И для меня это осталось загадкой до сих пор. Но в статье все это описано подробно.
.
Я так и знал. :)
А вот, кстати... Что в том коде, который я привел в статье про "засады", было не так? Вы ж прочитали статью? И где там была "мина", ась? ;)
Округа так плотно "заминирована", что избежать этого практически невозможно ;)
Спасибо за пожелания. Надеюсь, они искренние :)
Но "мужики-то знают" - "Всё начинается с любви… ". В нашем случае - с любви к математике. Она формализует те термины, вокруг которых ведутся все споры. С человеком, которые этого не понимает, разговаривать те то, что сложно - невозможно, т.к. языки общения разные.
Но когда "нащупаешь" истоки, то все становится сразу все ясно. Например, термины "параллелизм" или "скорость" или ... "асинхронность". Вы даже написали статью на эту тему - асинхронности. Но поскольку не задались с определением асинхронности, то получилось, может, и интересно, но как-то сумбурно и все свалилось в одну кучу ;) Это, конечно, мой взгляд, но... подобные статьи я могу читать только "по диагонали". Может и интересно, но вычленить суть довольно сложно. Хотя, казалось бы, темы-то общие.
Так и про "задержку". Я привел ее формальную модель. Математически строгую. Она объясняет, что такое задержка, какие они бывают и т.д. и т.п. Понимаете ли Вы, что такое "задержка". Какова ее роль вообще, а не только в программировании. Судя по комменту - есть определенные сомнения.
Вот как-то так. Начинать надо с "любви" (математики, конечно) :) И тогда, возможно, не придется "мучиться с многопоточностью".
А где и нужен ли файл pos_old.dat?
Совсем не так. Создание еще одного детерминированного автомата для ввода, скажем, символа на вход текущего автомата на не разрушает детерминированность текущего автомата. Причем даже если автомат ввода работает асинхронно текущему автомату. Но если Вы такой эстет и хотите сохранить детерминированность поведения системы тек.автомат+автомат ввода то синхронизируйте их работу в едином времени. Делов-то, как говорится ;)
Вы опять неправильно поняли. Мы можем детерминированным образом перейти от любой МТ к ее параллельной версии. По сути МТ это уже автомат (ее управление). Используя алгебру автоматов, можно любой одиночный автомат разложить на множество параллельных автоматов по операции умножения. Вот и все. И, кстати, это тоже будет детерминированная система - сеть автоматов. Ни какого недетерминизма нет и в помине.