Дык история в том, чтобы в основном потоке программы дать команду на остановку и не ждать его завершения и идти дальше.
Ну так вы будете только сигнал на остановку давать в StopAsync (т.е. только изменять значение TFStatus) и все. Не нужно ни дополнительного треда, ни ожидания.
Вызвали StopAsync, изменился TFStatus, вы пошли дальше. Рабочий тред увидел это изменение и завершился.
Если рабочий тред завершился до вызова деструктора ThreadedFunc, то все OK. Если не успел, то вы в деструкторе ThreadedFunc подождете этого на join-е.
Я правильно понимаю, что для того, чтобы "асинхронно" остановить уже запущенный тред вы стартуете в StopAsync новый тред? Т.е. одного рабочего треда мало и нужен второй?
Если у вас нет утилизации параллельных ядер CPU, то у вас нет никакого параллельного программирования. Ваш К.О.
Вы можете до посинения повторять мантры о "модели параллелизма", но до тех пор, пока ваши сущности живут в рамках одного рабочего треда, параллельного программирования у вас нет. От слова совсем. Просто по определению.
Как я понял, "параллельность" в ваших статьях относится к каскадированию КА. Но ставить знак равенства между вашей "параллельностью" и параллельным программированием... Мощно с вашей стороны, скажем так.
"Квазипараллелизм" он в современных потоках, корутинах, многоядерных системах и т.д. (перечисляете, что хотите).
Вы заблуждаетесь.
Вы программируете в рамках модели и как она реализована, что у ней под капотом по большому счету не должно интересовать программиста.
Ну да, ну да. Когда на машине программиста 24 вычислительных ядра, задействовать из которых рекламируемый вами VCPa может только одно(!!!), то современного программиста в современных условиях это ну никак не должно интересовать. lavrov.jpg
Тогда покажите в коде, где в вашем VCPa запускаются параллельно работающие треды. Или независимые процессы ОС, которые каким-то образом друг с другом могут обмениваться информацией, но работать реально параллельно.
читать состояние кстати, обычно можно без ограничения
Смотря что понимать под состоянием. Если только "имя" текущего состояния, то это одна история. При этом еще вопрос: а насколько разумно это делать, если мы сейчас прочитатли "имя" текущего состояния, а оно поменялось на другое еще до того, как мы из операции чтения вышли.
Если же под состоянием понимается не только "имя", но и какое-то содержимое объекта КА, то тут сразу же вопросы...
Опять же, все это актуально только если КА физически работают параллельно. А не квазипараллельно в рамках одного треда, как это, подозреваю, происходит у автора статьи.
Ох, теперь жалею, что невнимательно следил за этой веткой обсуждения. А то ведь фраза "Каждый из КА имеет доступ к текущим состояниям других КА", если я ее правильно понял, прекрасна своей незамутненностью.
Вы откровенно утомили своей манерой разговора в стиле "Я уже познал дзен, а вы читайте, читайте, читайте, все ссылки я дал". Когда это все множится на ваши говнотексты и суммируется с говнокодом в продвигаемой вами библиотеке, то смесь получается... Своеобразная, мягко говоря.
Использую этот подход (но не в embedded) много лет. Он хорош, но далеко не всегда, увы, в области concurrent computing. А в parallel computing, имхо, мало применим.
Сущность, которая представляет собой пользователя внутри программы так же вполне может быть КА. Отсюда и вырисовывается взаимодействие различных КА, причем независимых друг от друга.
Все таки этот пример далековато от темы статьи - контроллеры и устройства, где КА уместнее
Я долго не мог понять о какой параллельности говорит автор, смутило то, что статья помещена в хаб "параллельное программирование". Для меня параллельное программирование -- это parallel computing. Тогда как автор, видимо, говорит о параллельной связанности КА, что вовсе не обязательно должно означать параллельное исполнение самих КА (запросто может быть и всего лишь квазипараллелизм).
КА инкапсулируют разледеляемый ресурс - свое состояние.
Давайте попробуем более предметно и менее абстрактно.
Допустим, что у нас есть электронная табличка. По типу Google Sheets. С одной таблицей могут одновременно работать несколько пользователей. Допустим, работа каждого пользователя описывается своим КА.
Что с данными этой таблицы?
Два пользователя могут одновременно вводить в нее информацию. Причем, если они вносят новые значения в разные места таблицы, то делать они это могут реально в параллель.
При этом третий пользователь может в этот момент вести обсчет данных из таблицы. И в диапазон обсчета могут попасть как раз модифицируемые сейчас ячейки.
Или еще интереснее: один пользователь вводит данные в свою ячейку, которую сейчас не трогает пользователь №2. Но изменение ведет к пересчету значения в другой ячейки, которая сейчас как раз пользователю №2 нужна.
Если представлять данные таблицы в виде своего КА, то придется все запросы (на модификацию, на чтение и т.д.) сериализовать в последовательность запросов. Которая и обрабатываться будет последовательно. Что как бы не очень хорошо влияет на "параллельность".
Ваши статьи -- редкостное графоманство, написанное нечитаемым наукообразным языком.
А в комментариях вы ведете себя как высокомерный чудак на букву "М", который не может ответить на прямые простые вопросы прикрываясь мантрой "идите читайте".
Так да. Но я не говорил про "глобальное", я говорил про разделяемое мутабельное состояние. Оно не обязательно должно быть глобальным.
но чем Вас не устроил мой ответ
Во-первых, левой ссылкой. Во-вторых, отсутствием вменяемых пояснений по поводу того, как КА спасают от проблемы разделяемого мутабельного состояния при параллельном программировании. В-третьих, отсутствием ответов на ранее заданные вопросы.
что такое сеть автоматов, что такое общее состояние всех автоматов?
Вот это вот нуждается в расшифровке. Особенно "общее состояние" для параллельно и независимо работающих КА.
Кроме того, у меня сложилось ощущение, что под "параллельностью" вы понимаете что-то свое, известное только вам.
И еще одно ощущение: вы не сможете объяснить что лично вы вкладываете в понятие "параллельность".
Ваша ссылка ведет на статью под названием "Какие навыки необходимы на разных этапах карьеры". Вы ошиблись или реально искали там определение "разделяемое мутабельное состояние"?
Надеюсь, теперь понятно, как избавиться от "кошмара мутабельности"? :)
Нет. Не понято. Как и непонятно можете ли вы вообще связно излагать свои мысли на простом русском языке.
Если вы хотите поговорить здесь о разработке всерьез, то ответьте, пожалуйста, на заданные ранее вопросы. В частности, меня очень интересует вот что:
"Где связь между вашим наукообразным потоком сознания и "кошмарами", описанными в других статьях других авторов?
Пальцем ткните, пожалуйста. Мол, вот здесь проблема, вот мое решение."
Перечитайте еще раз тот мой пост из которого Вы заимствовали цитату.
Обычно за разгребание чужого говна мне платят. А вы хотите, чтобы я тратил на это время бесплатно? o_O
про сами кошмары - читайте других авторов
Тогда зачем ваша статья, если "кошмары" описывают другие люди, а вы предлагаете рецепты для лечения чего? Где связь между вашим наукообразным потоком сознания и "кошмарами", описанными в других статьях других авторов?
Пальцем ткните, пожалуйста. Мол, вот здесь проблема, вот мое решение.
Или Вы считаете, что их нет?
Сходу могу назвать один, главный -- разделяемое между параллельными задачами мутабельное состояние. Только вот в статье о нем что-то ничего не увидел. Может укажите на конкретный абзац или раздел?
Ну так вы будете только сигнал на остановку давать в StopAsync (т.е. только изменять значение TFStatus) и все. Не нужно ни дополнительного треда, ни ожидания.
Вызвали StopAsync, изменился TFStatus, вы пошли дальше.
Рабочий тред увидел это изменение и завершился.
Если рабочий тред завершился до вызова деструктора ThreadedFunc, то все OK.
Если не успел, то вы в деструкторе ThreadedFunc подождете этого на join-е.
Просто это решение вызывает большое удивление, поэтому и решил уточнить, а то как-то не верится.
Почему бы просто не сделать в деструкторе что-то вроде:
Если тред еще не завершился, то вы долждетесь его завершения. А если завершился (или не стартовал), то ничего и не будете ждать.
Я правильно понимаю, что для того, чтобы "асинхронно" остановить уже запущенный тред вы стартуете в StopAsync новый тред? Т.е. одного рабочего треда мало и нужен второй?
Г. П. Агибалов, Н. В. Евтушенко, Описание каскадных сетей конечных автоматов в терминах кодирований и покрытий, Пробл. передачи информ., 1982, том 18, выпуск 3, 74–84
По показателям загрузки вычислительных ядер в top/htop или TaskManager. Например.
Как можно быть, мягко говоря, настолько неумным человеком и еще что-то умудряться программировать? Ну, как?
Если у вас нет утилизации параллельных ядер CPU, то у вас нет никакого параллельного программирования. Ваш К.О.
Вы можете до посинения повторять мантры о "модели параллелизма", но до тех пор, пока ваши сущности живут в рамках одного рабочего треда, параллельного программирования у вас нет. От слова совсем. Просто по определению.
Как я понял, "параллельность" в ваших статьях относится к каскадированию КА. Но ставить знак равенства между вашей "параллельностью" и параллельным программированием... Мощно с вашей стороны, скажем так.
Вы заблуждаетесь.
Ну да, ну да. Когда на машине программиста 24 вычислительных ядра, задействовать из которых рекламируемый вами VCPa может только одно(!!!), то современного программиста в современных условиях это ну никак не должно интересовать. lavrov.jpg
Тогда покажите в коде, где в вашем VCPa запускаются параллельно работающие треды. Или независимые процессы ОС, которые каким-то образом друг с другом могут обмениваться информацией, но работать реально параллельно.
Я так понимаю, что это из-за того, что ваш VCPa все гоняет исключительно в одном рабочем треде.
Спасибо!
Смотря что понимать под состоянием. Если только "имя" текущего состояния, то это одна история. При этом еще вопрос: а насколько разумно это делать, если мы сейчас прочитатли "имя" текущего состояния, а оно поменялось на другое еще до того, как мы из операции чтения вышли.
Если же под состоянием понимается не только "имя", но и какое-то содержимое объекта КА, то тут сразу же вопросы...
Опять же, все это актуально только если КА физически работают параллельно. А не квазипараллельно в рамках одного треда, как это, подозреваю, происходит у автора статьи.
Не, не сталкивался, только из далека видел.
А ссылку на "мультиклет" могли бы подкинуть, чтобы не нагуглить чего-то левого?
мпп -- это massive parallel processing? Или что-то другое?
Ох, теперь жалею, что невнимательно следил за этой веткой обсуждения. А то ведь фраза "Каждый из КА имеет доступ к текущим состояниям других КА", если я ее правильно понял, прекрасна своей незамутненностью.
Вы откровенно утомили своей манерой разговора в стиле "Я уже познал дзен, а вы читайте, читайте, читайте, все ссылки я дал". Когда это все множится на ваши говнотексты и суммируется с говнокодом в продвигаемой вами библиотеке, то смесь получается... Своеобразная, мягко говоря.
Использую этот подход (но не в embedded) много лет. Он хорош, но далеко не всегда, увы, в области concurrent computing. А в parallel computing, имхо, мало применим.
Сущность, которая представляет собой пользователя внутри программы так же вполне может быть КА. Отсюда и вырисовывается взаимодействие различных КА, причем независимых друг от друга.
Я долго не мог понять о какой параллельности говорит автор, смутило то, что статья помещена в хаб "параллельное программирование". Для меня параллельное программирование -- это parallel computing. Тогда как автор, видимо, говорит о параллельной связанности КА, что вовсе не обязательно должно означать параллельное исполнение самих КА (запросто может быть и всего лишь квазипараллелизм).
Давайте попробуем более предметно и менее абстрактно.
Допустим, что у нас есть электронная табличка. По типу Google Sheets.
С одной таблицей могут одновременно работать несколько пользователей.
Допустим, работа каждого пользователя описывается своим КА.
Что с данными этой таблицы?
Два пользователя могут одновременно вводить в нее информацию. Причем, если они вносят новые значения в разные места таблицы, то делать они это могут реально в параллель.
При этом третий пользователь может в этот момент вести обсчет данных из таблицы. И в диапазон обсчета могут попасть как раз модифицируемые сейчас ячейки.
Или еще интереснее: один пользователь вводит данные в свою ячейку, которую сейчас не трогает пользователь №2. Но изменение ведет к пересчету значения в другой ячейки, которая сейчас как раз пользователю №2 нужна.
Если представлять данные таблицы в виде своего КА, то придется все запросы (на модификацию, на чтение и т.д.) сериализовать в последовательность запросов. Которая и обрабатываться будет последовательно. Что как бы не очень хорошо влияет на "параллельность".
На все вышеперечисленные.
Ваши статьи -- редкостное графоманство, написанное нечитаемым наукообразным языком.
А в комментариях вы ведете себя как высокомерный чудак на букву "М", который не может ответить на прямые простые вопросы прикрываясь мантрой "идите читайте".
Так да. Но я не говорил про "глобальное", я говорил про разделяемое мутабельное состояние. Оно не обязательно должно быть глобальным.
Во-первых, левой ссылкой.
Во-вторых, отсутствием вменяемых пояснений по поводу того, как КА спасают от проблемы разделяемого мутабельного состояния при параллельном программировании.
В-третьих, отсутствием ответов на ранее заданные вопросы.
Вот это вот нуждается в расшифровке. Особенно "общее состояние" для параллельно и независимо работающих КА.
Кроме того, у меня сложилось ощущение, что под "параллельностью" вы понимаете что-то свое, известное только вам.
И еще одно ощущение: вы не сможете объяснить что лично вы вкладываете в понятие "параллельность".
Ваша ссылка ведет на статью под названием "Какие навыки необходимы на разных этапах карьеры". Вы ошиблись или реально искали там определение "разделяемое мутабельное состояние"?
Нет. Не понято. Как и непонятно можете ли вы вообще связно излагать свои мысли на простом русском языке.
Если вы хотите поговорить здесь о разработке всерьез, то ответьте, пожалуйста, на заданные ранее вопросы. В частности, меня очень интересует вот что:
"Где связь между вашим наукообразным потоком сознания и "кошмарами", описанными в других статьях других авторов?
Пальцем ткните, пожалуйста. Мол, вот здесь проблема, вот мое решение."
Обычно за разгребание чужого говна мне платят. А вы хотите, чтобы я тратил на это время бесплатно? o_O
Тогда зачем ваша статья, если "кошмары" описывают другие люди, а вы предлагаете рецепты для лечения чего? Где связь между вашим наукообразным потоком сознания и "кошмарами", описанными в других статьях других авторов?
Пальцем ткните, пожалуйста. Мол, вот здесь проблема, вот мое решение.
Сходу могу назвать один, главный -- разделяемое между параллельными задачами мутабельное состояние. Только вот в статье о нем что-то ничего не увидел. Может укажите на конкретный абзац или раздел?