Comments 28
Аффтар, вы издеваетесь? Сегодня вроде бы не пятница, чтобы так тонко шутить
Поясните свой поинт
Ну каг бе так: какие выводы можно сделать из этой статьи, кроме того, что она написана технической точки зрения… ээ… с сомнительной граммотностью? Какую пользу эта статья принесет?
>>Волокна это легковесные объекты которые могли бы выполнять код, переключение между ними не ресурсоемко. Контроль кол-ва системных потоков
При чем тут системные потоки, если вы рассуждаете о fibers? Такому одаренному дауну, как я, например, очень сложно это понять.
>> логические потоки
Так логический поток — это не поток на самом деле, а абстракция цепочки вызовов между контекстами или AppDomain'ами. Это COMовская приблуда, связанная с COMAppartments, при чем здесь потоки ОС?
>>Волокна это легковесные объекты которые могли бы выполнять код, переключение между ними не ресурсоемко. Контроль кол-ва системных потоков
При чем тут системные потоки, если вы рассуждаете о fibers? Такому одаренному дауну, как я, например, очень сложно это понять.
>> логические потоки
Так логический поток — это не поток на самом деле, а абстракция цепочки вызовов между контекстами или AppDomain'ами. Это COMовская приблуда, связанная с COMAppartments, при чем здесь потоки ОС?
При том что в многопроцессорных системах эрланг выполняет маппинг логических потоков в физические (fibers 2 threads).
За самокритику +1 )))
За самокритику +1 )))
Как только вы покажете, где в статье упомянут Эрланг, мы продолжим дискуссию более предметно.
И еще — в windows (а .net работает преимущественно в windows), есть своя абстракция, называемая fibers. Это не совсем зеленые потоки, хотя и очень похожи.
Автору стоило хотя бы ознакомиться с терминологией той области, о которой он рассуждает, чтобы не придумывать на ходу термины, вызывающие коллизии.
И еще — в windows (а .net работает преимущественно в windows), есть своя абстракция, называемая fibers. Это не совсем зеленые потоки, хотя и очень похожи.
Автору стоило хотя бы ознакомиться с терминологией той области, о которой он рассуждает, чтобы не придумывать на ходу термины, вызывающие коллизии.
Я поддерживаю первый вариант
Статья поднимает важную тему, но является скорее констатацией, чем исследованием.
Программируя многопоточные приложения в течение нескольких лет, пришёл к полностью асинхронной модели взаимодействия потоков. Всё это позволило мне отказаться от (явного) использования объектов синхронизации.
Как ни странно, выросла не только стабильность работы, но и простота отладки. В конечном итоге, оказалось что асинхронный подход сильно снижает затраты на разработку многопоточных приложений, уже хотя бы потому что исчезает огромное количество проблем и потенциальных неприятностей вроде deadlock.
Всё это дело было реализовано в рамках одного их кроссплатфороменных фреймворков на С++. Тесты показали очевидную вещь: за всё приходится платить, и иногда данный подход себя оправдывает. О чём конкретно речь? Асинхронная модель предполагает наличие у каждого потока очереди сообщений (в моём случае я вместо сообщений храню указатели на функции и их аргументы). Очевидно, это приводит к увеличению использования оперативной памяти и работы процессора по переносу (копированию) вышеозначенных элементов очереди.
Таким образом, асинхронный подход с очередью сообщений актуален для применений, где этих сообщений не так много (не больше нескольких десятков тысяч в секунду). Это актуально для большинства прикладных программ (увы, всякие серьёзные вещи вроде серверов зачастую требуют большее быстродействие). Если условие выполняется, то есть хороший шанс написать программу, избавив себя от большинства проблем с многопоточностью.
Как пример, приведу свою прошлую программу, где шесть потоков почти не потребовали отладки при синхронизации, из-за использования асинхронного подхода и очередей.
Программируя многопоточные приложения в течение нескольких лет, пришёл к полностью асинхронной модели взаимодействия потоков. Всё это позволило мне отказаться от (явного) использования объектов синхронизации.
Как ни странно, выросла не только стабильность работы, но и простота отладки. В конечном итоге, оказалось что асинхронный подход сильно снижает затраты на разработку многопоточных приложений, уже хотя бы потому что исчезает огромное количество проблем и потенциальных неприятностей вроде deadlock.
Всё это дело было реализовано в рамках одного их кроссплатфороменных фреймворков на С++. Тесты показали очевидную вещь: за всё приходится платить, и иногда данный подход себя оправдывает. О чём конкретно речь? Асинхронная модель предполагает наличие у каждого потока очереди сообщений (в моём случае я вместо сообщений храню указатели на функции и их аргументы). Очевидно, это приводит к увеличению использования оперативной памяти и работы процессора по переносу (копированию) вышеозначенных элементов очереди.
Таким образом, асинхронный подход с очередью сообщений актуален для применений, где этих сообщений не так много (не больше нескольких десятков тысяч в секунду). Это актуально для большинства прикладных программ (увы, всякие серьёзные вещи вроде серверов зачастую требуют большее быстродействие). Если условие выполняется, то есть хороший шанс написать программу, избавив себя от большинства проблем с многопоточностью.
Как пример, приведу свою прошлую программу, где шесть потоков почти не потребовали отладки при синхронизации, из-за использования асинхронного подхода и очередей.
Реализовать это самостоятельно сложно, т.к. не документирована работа с логическими тредами в .NET Runtime.
А они вообще есть?
Посмотрите на то что это за зверь Thread в .NET а также почему его ID не гарантирован соответствовать системному идентификатору потока. В общем в .NET потоки считаются логическими.
Поройте в сторону Axum думаю вам будет интересно…
Для решения проблем асинхронного программирования нужны две вещи — грамотный алгоритм и башковитый программист
От обертки уже мало что зависит
От обертки уже мало что зависит
Согласитесь что подобный подход к решению проблемы не дешевый, хороший программист == хорошая зарплата.
Следовательно это не общее решение.
Следовательно это не общее решение.
linq to events частично исправляет это дело.
Язык высокого уровня это не «обертка» над машинным кодом? Она вам не помогает? Предпочитаете вдумчиво писать байт-коды?
Развитие технологий предполагают сделать жизнь проще, разве не так?
Развитие технологий предполагают сделать жизнь проще, разве не так?
Вот он! Чак Норис! Он может управлять потоками взглядом :)))
PS: Вы на самом деле меня насмешили. Проблема не в том чтобы решить «проблемы» асинхронного програмирования, а в том что на них приходиться тратить время… а время — драгоценно!
PS: Вы на самом деле меня насмешили. Проблема не в том чтобы решить «проблемы» асинхронного програмирования, а в том что на них приходиться тратить время… а время — драгоценно!
Sign up to leave a comment.
Асинхронная модель программирования (часть 1)