Весьма интересно. Ссылку на статью вы увидите в тексте новости, но там еще в комментариях есть хорошая ссылка, на видео лекцию.
Показаны сообщения с ярлыком Многопоточность. Показать все сообщения
Показаны сообщения с ярлыком Многопоточность. Показать все сообщения
Microsoft включит в Visual Studio средства параллельного программирования на графических процессорах
Полный текст новости:
На конференции AMD Fusion Developer Summit корпорация Microsoft представила технологию поддержки параллельного программирования на графических процессорах под названием C++ Accelerated Massive Parallelism (C++ AMP). Она будет реализована в следующей версии компилятора Visual C++ и интегрированной среды разработки Visual Studio.
C++ AMP основывается на технологиях Microsoft DirectX, исходно создававшихся для мультимедийных приложений на платформе Windows. Благодаря этому C++ AMP сможет работать на оборудовании всех основных производителей, пишет старший президент Microsoft Developer Division С. Сомасегар. Кроме того, спецификация C++ AMP будет открытой.
Программирование на графических процессорах в последние годы с большим успехом используется в ряде узких областей. В Microsoft рассчитывают, что созданные ими средства позволят применять эти технологии в массовых разработках.
В следующую версию Visual Studio будут включены также усовершенствованные библиотеки Parallel Patterns Library и C++ Concurrency, содержащие ряд шаблонов и алгоритмов для параллельного программирования на любых процессорах.
Вопрос на засыпку
У вас есть приложение. Следует сделать его многопоточным. Назовите 3 вида декомпозиции, которыми следует руководствоваться при решении этой задачи.
Вот придете ко мне на собеседование, будет такой вопрос, не знаете - до свидания.
Или другая ситуация - кто-то сейчас выяснит у меня приватом ответ и сам будет задавать его, на собеседовании уже в другой фирме. Мы плавно подошли к одному из паттернов параллельного выполнения программ - "Паттерн волнового фронта". Но сейчас речь не об этом...
Вот придете ко мне на собеседование, будет такой вопрос, не знаете - до свидания.
Или другая ситуация - кто-то сейчас выяснит у меня приватом ответ и сам будет задавать его, на собеседовании уже в другой фирме. Мы плавно подошли к одному из паттернов параллельного выполнения программ - "Паттерн волнового фронта". Но сейчас речь не об этом...
Транзакционная память
В процессе подготовки материала к продолжению "Разбираемся с JBoss Transactions. Часть 1", пришлось как раз изучить, что такое эта транзакционная память - "Software transactional memory (Википедия, English)".
Достаточно сказать, что она вошла в состав новейшего .NET 4, вполне достаточно, чтобы попробовать изучить.
Как явствует из Википедии (ссылка выше) - это модель работы с многопоточностью, применяемая часто в СУБД, которая коренным образом отличается от lock-модели.
Плюсы достаточно интересны - во-первых она более проста для понимания и использования, чем lock-модель. Во-вторых она может быть и более быстрой (не всегда, но при каких-то условиях и сильно еще зависит от конкретной реализации). В-третьих, по уверению авторов, она менее подвержена такому КРАЙНЕ нехорошему моменту в многопоточности, как инверсия приоритетов. О последнем могут не беспокоиться пользователи операционной системы реального времени QNX, а вот пользователи Windows большинства версий, Linux, FreeBSD - мягко говоря - "сосут лапу", их ОС не защищены от инверсии приоритетов в многопоточности. При определенных обстоятельствах поток с небольшим приоритетом может не получать возможность работы относительно долго, вполне достаточно для непредотвращения взрыва ядерного реактора ответственным за глушение его потоком выполнения.
Итак, чем же характеризуется модель многопоточного программирования "Транзакционная память". Модель очень проста:
1) Есть какое-то место в программе, разделяемое между несколькими потоками, какие-то данные, для краткости назовем их переменными "a" и "b".
2) Нужно обеспечить атомарность изменения переменных "a" и "b" разными потоками. Например поток 1-ый делает инкремент обеим переменным, 2-ой - декремент обеим этим переменным, при этом нужно чтобы потоки делали этим изменения последовательно, сначала один из них начал работу, закончил, только тогда второй поток может тоже начать изменять их.
3) Lock-модель делает блокировку этого места в коде. При этом только один поток работает с залоченными местом в коде, остальные потоки ждут, когда и им дадут возможность поработать с этим местом кода тоже. Транзакционная память делает иначе - она позволяет ВСЕМ получать доступ к этому месту кода. Фишка тут в следующем, - ПЕРЕД тем как начать изменять (или просто считывать) переменные "a" и "b" - выполняющийся поток увеличивает значение или изменяет флаг какой-то особой переменной, выделенной для этой цели - назовем эту переменную как "z". Смотрите - поток изменяет флаг в "z", после этого работает с участком кода, где переменные "a" и "b". ПОСЛЕ этого, как данный поток внес изменения в "a" и "b" - он проверяет значение флага в переменной "z". Если значение флага в "z" не изменилось, значит никто не "покусился" за это время на переменные "a" и "b". Если изменилось, значит транзакция нарушена и, что нужно сделать в таком случае? - правильно, откат транзакции! Поток еще раз пробует поставить значение флага "z" и внести изменения в переменные "a" и "b". Все очень зависит от процессора и подсистем памяти - вполне возможно, что многие потоки получат достаточно времени, что гарантированно внести изменения в это место - и успеть поставить флаг и поменять обе переменные, пока данный поток не будет вытеснен другим потоком.
И дело вот еще в чем, про это не знает абсолютное большинство Java-программистов - вы можете затипизировать переменные "a" и "b" особыми атомарными типами, которые есть в Java. Да вот в чем незадача - атомарность эта достигается за счет полного блокирования системной шины. Ваша система может таким "колом" встать от этой атомарности, что подумайте - стоит ли применять. Вместе с тем ДАННАЯ модель многопоточного программирования - может использовать атомарность только для работы с переменной "z", а не с "a" и "b". В простейшем моем, сильно утрированном примере - вы всего 1 раз поставить на кол всю систему, а не 2 раза. Теперь "введите" десять потоков, которые доведут до ручки систему, если использовать "обычный" "атомарный" подход в Java.
Тем более при изменении таких нескольких переменных - помимо атомарности все равно нужно вводить синхронизацию на это место в коде, при lock-подходе.
Минусы:
1) Не возможно отменять большинство операций, связанных с I/O. Правда в некоторых реализациях транзакционной памяти применяют буферы, чтобы обойти этот момент.
2) Может быть высокий рост производительности (как и бОльшая понятность кода и более проще отладить), но это смотря сколько процессоров в вашей системе и еще некоторых факторов.
Более подробно вы можете изучить в Википедии - "Software transactional memory (English)"
Используется сокращение - STM (Software transactional memory).
Достаточно сказать, что она вошла в состав новейшего .NET 4, вполне достаточно, чтобы попробовать изучить.
Как явствует из Википедии (ссылка выше) - это модель работы с многопоточностью, применяемая часто в СУБД, которая коренным образом отличается от lock-модели.
Плюсы достаточно интересны - во-первых она более проста для понимания и использования, чем lock-модель. Во-вторых она может быть и более быстрой (не всегда, но при каких-то условиях и сильно еще зависит от конкретной реализации). В-третьих, по уверению авторов, она менее подвержена такому КРАЙНЕ нехорошему моменту в многопоточности, как инверсия приоритетов. О последнем могут не беспокоиться пользователи операционной системы реального времени QNX, а вот пользователи Windows большинства версий, Linux, FreeBSD - мягко говоря - "сосут лапу", их ОС не защищены от инверсии приоритетов в многопоточности. При определенных обстоятельствах поток с небольшим приоритетом может не получать возможность работы относительно долго, вполне достаточно для непредотвращения взрыва ядерного реактора ответственным за глушение его потоком выполнения.
Итак, чем же характеризуется модель многопоточного программирования "Транзакционная память". Модель очень проста:
1) Есть какое-то место в программе, разделяемое между несколькими потоками, какие-то данные, для краткости назовем их переменными "a" и "b".
2) Нужно обеспечить атомарность изменения переменных "a" и "b" разными потоками. Например поток 1-ый делает инкремент обеим переменным, 2-ой - декремент обеим этим переменным, при этом нужно чтобы потоки делали этим изменения последовательно, сначала один из них начал работу, закончил, только тогда второй поток может тоже начать изменять их.
3) Lock-модель делает блокировку этого места в коде. При этом только один поток работает с залоченными местом в коде, остальные потоки ждут, когда и им дадут возможность поработать с этим местом кода тоже. Транзакционная память делает иначе - она позволяет ВСЕМ получать доступ к этому месту кода. Фишка тут в следующем, - ПЕРЕД тем как начать изменять (или просто считывать) переменные "a" и "b" - выполняющийся поток увеличивает значение или изменяет флаг какой-то особой переменной, выделенной для этой цели - назовем эту переменную как "z". Смотрите - поток изменяет флаг в "z", после этого работает с участком кода, где переменные "a" и "b". ПОСЛЕ этого, как данный поток внес изменения в "a" и "b" - он проверяет значение флага в переменной "z". Если значение флага в "z" не изменилось, значит никто не "покусился" за это время на переменные "a" и "b". Если изменилось, значит транзакция нарушена и, что нужно сделать в таком случае? - правильно, откат транзакции! Поток еще раз пробует поставить значение флага "z" и внести изменения в переменные "a" и "b". Все очень зависит от процессора и подсистем памяти - вполне возможно, что многие потоки получат достаточно времени, что гарантированно внести изменения в это место - и успеть поставить флаг и поменять обе переменные, пока данный поток не будет вытеснен другим потоком.
И дело вот еще в чем, про это не знает абсолютное большинство Java-программистов - вы можете затипизировать переменные "a" и "b" особыми атомарными типами, которые есть в Java. Да вот в чем незадача - атомарность эта достигается за счет полного блокирования системной шины. Ваша система может таким "колом" встать от этой атомарности, что подумайте - стоит ли применять. Вместе с тем ДАННАЯ модель многопоточного программирования - может использовать атомарность только для работы с переменной "z", а не с "a" и "b". В простейшем моем, сильно утрированном примере - вы всего 1 раз поставить на кол всю систему, а не 2 раза. Теперь "введите" десять потоков, которые доведут до ручки систему, если использовать "обычный" "атомарный" подход в Java.
Тем более при изменении таких нескольких переменных - помимо атомарности все равно нужно вводить синхронизацию на это место в коде, при lock-подходе.
Минусы:
1) Не возможно отменять большинство операций, связанных с I/O. Правда в некоторых реализациях транзакционной памяти применяют буферы, чтобы обойти этот момент.
2) Может быть высокий рост производительности (как и бОльшая понятность кода и более проще отладить), но это смотря сколько процессоров в вашей системе и еще некоторых факторов.
Более подробно вы можете изучить в Википедии - "Software transactional memory (English)"
Используется сокращение - STM (Software transactional memory).
Microsoft Visual Studio 2010 и .NET Framework 4 уже в России
Публикация в новостях - "Microsoft Visual Studio 2010 и .NET Framework 4 уже в России".
Полный текст новости:
"Компания Microsoft объявила о выходе новой версии платформы разработки Visual Studio 2010 и среды выполнения .NET Framework 4. Эти технологии призваны упростить весь процесс разработки, предоставляя необходимые инструменты и рабочую среду для реализации последних нововведений при проектировании архитектур, разработке и внедрении, говорится в сообщении корпорации. Около 50 партнеров уже объявили о доступности своих продуктов и решений на базе Visual Studio. Среди них Intel, Quest, JetBrains и DevExpress.
Платформа разработки Visual Studio 2010 предлагает инструменты не только для создания уже привычных программных решений – для мобильных телефонов, ПК или бизнеса, но и «облачных» приложений. И что особенно важно – тестирование, отладка и развертывание в «облаке» похожи на создание .NET-приложений, что облегчает создание «облачных» решений, подчеркнули разработчики.
Еще одним ключевым дополнением являются инструменты для многопоточной разработки с использованием как неуправляемого кода, так и .NET Framework. Многопоточное программирование позволяет создавать приложения, которые используют возможности широко распространенных сегодня многоядерных аппаратных платформ. Новая Visual Studio 2010 помогает разрабатывать ПО, которое может распределять вычислительную нагрузку между множеством процессоров, и для этого не требуется напрямую работать с потоками. Платформа предлагает новые инструменты для анализа многопоточных приложений в профилировщике и отладчике Visual Studio.
Среди других важных дополнений можно отметить полностью переработанный интерфейс с использованием Windows Presentation Foundation (WPF), который позволяет реализовать такие концепции, как множественные мониторы, благодаря чему разработчик может использовать один монитор для кода, другой – для дизайна интерфейса, а третий – для проектирования структур баз данных. Редактор кода в Visual Studio 2010 также создан с нуля с использованием WPF, что позволяет представлять в редакторе разнообразную информацию о коде в различных контекстах.
В новой Visual Studio 2010 включено следующее поколение инструментов ASP.NET, предоставляющих уникальную модель, которая делает веб-разработку доступной для разработчиков традиционных приложений. Например, облегчается использование таблиц при создании веб-сайтов, базирующихся на технологии Model-View-Controller (MVC). Также упрощен процесс развертывания приложений ASP.NET и веб-сайтов. Кроме того, Visual Studio 2010 станет первой версией среды, которая включает JQuery как часть инструментов ASP.NET, отметили в Microsoft.
Visual Studio 2010 оснащена поддержкой динамических расширений в языках программирования C# и Visual Basic, что упрощает взаимодействие с новыми динамическими языками IronPython и IronRuby, а также работу с объектной моделью веб-страниц и Silverlight. Также ряд улучшений сделали среду разработки Visual C++ более производительной, особенно при работе с большими приложениями. Многие компоненты среды разработки, такие как IntelliSense, выполняют синтаксический анализ и обработку файлов в фоновом режиме. Обновленные возможности IntelliSense обеспечивают большую точность кода. Теперь можно удобно работать со сложными конструкцями C++-кода и макросами, чего не было в предыдущей версии.
В то же время, Visual Studio 2010 предлагает новые возможности для создания приложений под Windows 7, Office 2010 и SharePoint 2010. Новые шаблоны проектов для Sharepoint помогут быстро создавать и редактировать такие элементы, как списки определений, списки экземпляров, определения узлов, рабочие процессы, приемники событий, модели Business Data Catalog и др. В Visual Studio 2010 разработчики могут создавать клиентские Office-приложения (32-х и 64-х битные), поддерживающие множество версий Office, и собирать их в единый пакет для развертывания. По информации Microsoft, задача создания приложений стала проще благодаря поддержке удобного пользовательского интерфейса, выполненного на WPF или Fluent. При помощи этих инструментов разработчики смогут изменять меню приложений Office, панелей задач, форм Outlook и элементов самого интерфейса Fluent (как, например, Ribbon). Приложения могут взаимодействовать с различными объектами Office, например, списками и панелями операций, а также работать с Office Live Viewer.
Разработчики приложений для Windows 7 получили большое количество новых библиотек, поддерживающих Windows 7, обновление MFC, включающее новые элементы Windows 7, такие как Ribbon, Live icons, интеграцию с поиском и поддержку multi-touch.
Visual Studio 2010 также предоставляет новые возможности для всех специалистов, которые нуждаются в управлении жизненным циклом: от архитекторов и разработчиков до менеджеров проекта и инженеров по тестированию. Как отмечается, ключевым фактором понимания структуры приложений являются инструменты моделирования. Подход Microsoft заключается в предоставлении техническому и нетехническому персоналу возможностей применять моделирование в коллективной работе и описывать бизнес- и системную функциональность графически. Так, среди новых возможностей: улучшенный анализ существующего кода с использованием Architecture Explorer; совместная работа над многочисленными типами UML-диаграмм, включая use-case, activity- и sequence-диаграммы; инструментарий для документирования тестовых сценариев; возможность идентификации и тестирования только измененного кода с Test Impact View; улучшенная система контроля версий, включая gated check-in, визуализацию ветвей и гибкую настройку процесса сборки; возможности управления лабораторией тестирования с помощью Visual Studio Lab Management 2010 – она позволяет быстро создавать виртуальные среды, включающие множество компьютеров, развертывать приложение, выполнять тесты и формировать детальные отчеты об ошибках.
«Visual Studio 2010 значительно прибавила в качестве и быстродействии, в основном она работает быстрее Visual Studio 2008, – заявил Владимир Гусаров, руководитель проектов Quest Software. – Разработчику теперь будет трудно сказать, что он не может воспроизвести ошибку. Новый революционный Team Foundation Server 2010 предоставляет богатые возможности для командной разработки, такие как Hierarchical Work Items, Gated Check-in и Test and Lab Management»."
UPD 1. Публикация в новостях - "Русская версия Visual Studio 2010 выйдет в мае".
Полный текст новости:
"Компания Microsoft объявила о выходе новой версии платформы разработки Visual Studio 2010 и среды выполнения .NET Framework 4. Эти технологии призваны упростить весь процесс разработки, предоставляя необходимые инструменты и рабочую среду для реализации последних нововведений при проектировании архитектур, разработке и внедрении, говорится в сообщении корпорации. Около 50 партнеров уже объявили о доступности своих продуктов и решений на базе Visual Studio. Среди них Intel, Quest, JetBrains и DevExpress.
Платформа разработки Visual Studio 2010 предлагает инструменты не только для создания уже привычных программных решений – для мобильных телефонов, ПК или бизнеса, но и «облачных» приложений. И что особенно важно – тестирование, отладка и развертывание в «облаке» похожи на создание .NET-приложений, что облегчает создание «облачных» решений, подчеркнули разработчики.
Еще одним ключевым дополнением являются инструменты для многопоточной разработки с использованием как неуправляемого кода, так и .NET Framework. Многопоточное программирование позволяет создавать приложения, которые используют возможности широко распространенных сегодня многоядерных аппаратных платформ. Новая Visual Studio 2010 помогает разрабатывать ПО, которое может распределять вычислительную нагрузку между множеством процессоров, и для этого не требуется напрямую работать с потоками. Платформа предлагает новые инструменты для анализа многопоточных приложений в профилировщике и отладчике Visual Studio.
Среди других важных дополнений можно отметить полностью переработанный интерфейс с использованием Windows Presentation Foundation (WPF), который позволяет реализовать такие концепции, как множественные мониторы, благодаря чему разработчик может использовать один монитор для кода, другой – для дизайна интерфейса, а третий – для проектирования структур баз данных. Редактор кода в Visual Studio 2010 также создан с нуля с использованием WPF, что позволяет представлять в редакторе разнообразную информацию о коде в различных контекстах.
В новой Visual Studio 2010 включено следующее поколение инструментов ASP.NET, предоставляющих уникальную модель, которая делает веб-разработку доступной для разработчиков традиционных приложений. Например, облегчается использование таблиц при создании веб-сайтов, базирующихся на технологии Model-View-Controller (MVC). Также упрощен процесс развертывания приложений ASP.NET и веб-сайтов. Кроме того, Visual Studio 2010 станет первой версией среды, которая включает JQuery как часть инструментов ASP.NET, отметили в Microsoft.
Visual Studio 2010 оснащена поддержкой динамических расширений в языках программирования C# и Visual Basic, что упрощает взаимодействие с новыми динамическими языками IronPython и IronRuby, а также работу с объектной моделью веб-страниц и Silverlight. Также ряд улучшений сделали среду разработки Visual C++ более производительной, особенно при работе с большими приложениями. Многие компоненты среды разработки, такие как IntelliSense, выполняют синтаксический анализ и обработку файлов в фоновом режиме. Обновленные возможности IntelliSense обеспечивают большую точность кода. Теперь можно удобно работать со сложными конструкцями C++-кода и макросами, чего не было в предыдущей версии.
В то же время, Visual Studio 2010 предлагает новые возможности для создания приложений под Windows 7, Office 2010 и SharePoint 2010. Новые шаблоны проектов для Sharepoint помогут быстро создавать и редактировать такие элементы, как списки определений, списки экземпляров, определения узлов, рабочие процессы, приемники событий, модели Business Data Catalog и др. В Visual Studio 2010 разработчики могут создавать клиентские Office-приложения (32-х и 64-х битные), поддерживающие множество версий Office, и собирать их в единый пакет для развертывания. По информации Microsoft, задача создания приложений стала проще благодаря поддержке удобного пользовательского интерфейса, выполненного на WPF или Fluent. При помощи этих инструментов разработчики смогут изменять меню приложений Office, панелей задач, форм Outlook и элементов самого интерфейса Fluent (как, например, Ribbon). Приложения могут взаимодействовать с различными объектами Office, например, списками и панелями операций, а также работать с Office Live Viewer.
Разработчики приложений для Windows 7 получили большое количество новых библиотек, поддерживающих Windows 7, обновление MFC, включающее новые элементы Windows 7, такие как Ribbon, Live icons, интеграцию с поиском и поддержку multi-touch.
Visual Studio 2010 также предоставляет новые возможности для всех специалистов, которые нуждаются в управлении жизненным циклом: от архитекторов и разработчиков до менеджеров проекта и инженеров по тестированию. Как отмечается, ключевым фактором понимания структуры приложений являются инструменты моделирования. Подход Microsoft заключается в предоставлении техническому и нетехническому персоналу возможностей применять моделирование в коллективной работе и описывать бизнес- и системную функциональность графически. Так, среди новых возможностей: улучшенный анализ существующего кода с использованием Architecture Explorer; совместная работа над многочисленными типами UML-диаграмм, включая use-case, activity- и sequence-диаграммы; инструментарий для документирования тестовых сценариев; возможность идентификации и тестирования только измененного кода с Test Impact View; улучшенная система контроля версий, включая gated check-in, визуализацию ветвей и гибкую настройку процесса сборки; возможности управления лабораторией тестирования с помощью Visual Studio Lab Management 2010 – она позволяет быстро создавать виртуальные среды, включающие множество компьютеров, развертывать приложение, выполнять тесты и формировать детальные отчеты об ошибках.
«Visual Studio 2010 значительно прибавила в качестве и быстродействии, в основном она работает быстрее Visual Studio 2008, – заявил Владимир Гусаров, руководитель проектов Quest Software. – Разработчику теперь будет трудно сказать, что он не может воспроизвести ошибку. Новый революционный Team Foundation Server 2010 предоставляет богатые возможности для командной разработки, такие как Hierarchical Work Items, Gated Check-in и Test and Lab Management»."
UPD 1. Публикация в новостях - "Русская версия Visual Studio 2010 выйдет в мае".
Многозадачность на мобильных платформах
Фанаты каждой платформы шумели и шумели на счет других платформ, но появилась разъясняющая информация, которую и приведу.
Если в двух словах, то и на андроидо-гуглофонах, и на iPhone, и на Windows Mobile 7 - все будет обстоять следующим образом - разработчик делает GUI-часть, которая может вытесняться из ОЗУ с сохранением или без сохранения состояния + разработчик делает часть, которую можно назвать как Service. Service работает постоянно, при любых условиях. ПОМИМО этого - вроде во всех трех платформах будут или уже есть - всплывающие сообщения/уведомления о фоновых задачах.
А если более подробно, то про Windows Phone 7 написано здесь, а по другим двум платформам попался на глаза такой комментарий в Интернете:
"> Коллеги, а как организованна многозадачность в андроиде?
упрощённо, есть два вида сущностей в приложении: Activity и Service.
Первое - полная аналогия с тем, что делает сейчас Apple. Activity фризится (если уходит в фон) и если требуется свободная память - выгружается. При повторном обращении пользователя, оно либо снова запускается, либо экземпляр пересоздаётся и запускается с нуля.
Service имеет право работать в фоне всегда. Поэтому относительно серьёзные приложения создаются в виде пары клиент (кучка Activity)-сервис (Service). Service ограничен только фантазией разработчика. Хошь в фоне считать число Пи - считай.
Ещё есть broadcast recievers и content providers. Они существуют только в момент определённых вызовов: получения Intent (грубо говоря, сообщения) и обращения к данным соответственно."
И вот еще несколько любопытных комментариев:
"Мда, чувствую что свою нокию (симбиан - многозадачен), менять кроме как на андроид больше ни на что не захочу.... Есть еще другие Linux-based, но они пока в зачаточном состоянии...."
"Делаем на iPhone джейлбрейк и скачиваем из Сидии Бэкраундер. В итоге получаем 100%-но полную многозадачность. Программы переключать, как вкладки в Safari листать. Работает абсолютно для всех программ, прям как на компьютере. Минус тока один, при запуске нескольких мощных приложений может начать жутко тормозить, ибо оперативная память не резиновая."
"> Итог: на сегодняшний день Windows Mobile 6.5.x по-прежнему остаётся единственной полноценной многозадачной системой для мобильных устройств.
не порите чушь. Блакбери ОС занимает доминирующее положение на американском рынке смартфонов и поддерживает до 64 задач в паралель."
Если в двух словах, то и на андроидо-гуглофонах, и на iPhone, и на Windows Mobile 7 - все будет обстоять следующим образом - разработчик делает GUI-часть, которая может вытесняться из ОЗУ с сохранением или без сохранения состояния + разработчик делает часть, которую можно назвать как Service. Service работает постоянно, при любых условиях. ПОМИМО этого - вроде во всех трех платформах будут или уже есть - всплывающие сообщения/уведомления о фоновых задачах.
А если более подробно, то про Windows Phone 7 написано здесь, а по другим двум платформам попался на глаза такой комментарий в Интернете:
"> Коллеги, а как организованна многозадачность в андроиде?
упрощённо, есть два вида сущностей в приложении: Activity и Service.
Первое - полная аналогия с тем, что делает сейчас Apple. Activity фризится (если уходит в фон) и если требуется свободная память - выгружается. При повторном обращении пользователя, оно либо снова запускается, либо экземпляр пересоздаётся и запускается с нуля.
Service имеет право работать в фоне всегда. Поэтому относительно серьёзные приложения создаются в виде пары клиент (кучка Activity)-сервис (Service). Service ограничен только фантазией разработчика. Хошь в фоне считать число Пи - считай.
Ещё есть broadcast recievers и content providers. Они существуют только в момент определённых вызовов: получения Intent (грубо говоря, сообщения) и обращения к данным соответственно."
И вот еще несколько любопытных комментариев:
"Мда, чувствую что свою нокию (симбиан - многозадачен), менять кроме как на андроид больше ни на что не захочу.... Есть еще другие Linux-based, но они пока в зачаточном состоянии...."
"Делаем на iPhone джейлбрейк и скачиваем из Сидии Бэкраундер. В итоге получаем 100%-но полную многозадачность. Программы переключать, как вкладки в Safari листать. Работает абсолютно для всех программ, прям как на компьютере. Минус тока один, при запуске нескольких мощных приложений может начать жутко тормозить, ибо оперативная память не резиновая."
"> Итог: на сегодняшний день Windows Mobile 6.5.x по-прежнему остаётся единственной полноценной многозадачной системой для мобильных устройств.
не порите чушь. Блакбери ОС занимает доминирующее положение на американском рынке смартфонов и поддерживает до 64 задач в паралель."
Google представил свой язык программирования
Публикация в новостях - "Google представил свой язык программирования".
Цитаты:
"Компания Google представила собственный новый язык программирования под названием Go, который ориентирован на "быструю разработку". Он позволит создавать различные приложения с поддержкой многоядерных процессоров и параллельных вычислений.
...
По словам представителей компании, Go — это экспериментальный язык, который объединяет в себе высокую производительность и безопасность C++ со скоростью динамических языков программирования, таких как Python."
Комментарии под новостью:
"Усё пожрал проклятый суслик...
Как назвать программера, пишущего на Go?
Goпник?
http://golang.org/
чё стебаццо? быстро скачали, поставили и начали кодить!
неужели неинтересно?
гуглоось только на линуксе....
>> Посмотрел http://golang.org/doc/go_faq.html но так и не понял зачем он нужен :-(
> Я тоже не понял, чем этот пример лучше чем:
> include
> int main() {
> printf("Hello, world\n");
> }
> Изобрели велосипед называется.
ну чтож тут непонятного этот пример будет скомпилирован и выполнен многопоточно"
Цитаты:
"Компания Google представила собственный новый язык программирования под названием Go, который ориентирован на "быструю разработку". Он позволит создавать различные приложения с поддержкой многоядерных процессоров и параллельных вычислений.
...
По словам представителей компании, Go — это экспериментальный язык, который объединяет в себе высокую производительность и безопасность C++ со скоростью динамических языков программирования, таких как Python."
Комментарии под новостью:
"Усё пожрал проклятый суслик...
Как назвать программера, пишущего на Go?
Goпник?
http://golang.org/
чё стебаццо? быстро скачали, поставили и начали кодить!
неужели неинтересно?
гуглоось только на линуксе....
>> Посмотрел http://golang.org/doc/go_faq.html но так и не понял зачем он нужен :-(
> Я тоже не понял, чем этот пример лучше чем:
> include
> int main() {
> printf("Hello, world\n");
> }
> Изобрели велосипед называется.
ну чтож тут непонятного этот пример будет скомпилирован и выполнен многопоточно
"
Выпуск 100-ядерного процессора намечен на 2011 г.
В то время, как "Intel думает о тысячах ядер на процессор" (публикация за прошлый год), калифорнийский стартап Tilera информирует, что у него - "выпуск 100-ядерного процессора намечен на 2011 г.".
Цитата:
"Молодая калифорнийская компания Tilera планирует в 2011 г. приступить к поставкам 100-ядерных процессоров многоцелевого назначения, сообщает Wired. «Процессор будет как минимум в четыре раза мощнее процессоров Intel на архитектуре Intel Nehalem и потреблять втрое меньше энергии по сравнению с ними», - заявили разработчики.
Tilera была основана в 2004 г. ..."
Цитата:
"Молодая калифорнийская компания Tilera планирует в 2011 г. приступить к поставкам 100-ядерных процессоров многоцелевого назначения, сообщает Wired. «Процессор будет как минимум в четыре раза мощнее процессоров Intel на архитектуре Intel Nehalem и потреблять втрое меньше энергии по сравнению с ними», - заявили разработчики.
Tilera была основана в 2004 г. ..."
Java. Программирование на сокетах. Best practics
В 8-ом издании (для любопытствующих могу проверить в 7-ом издание, слишком давно читал его) 2-ого тома книги Хорстманна о J2SE - упоминается лучшая практика по программированию многопоточного сокет-сервера, с применением пакета неблокирующего чтения средствами пакета nio.
К сожалению - материал на английском, на сайте IBM.
Материал очень хорошо оформлен, есть поясняющие UML-диаграммы, показывающие зависимости используемых интерфейсов.
Можно скачать пример с кодом (чуть-чуть его придется подпилить, в сущих пустяках, которые покажет вам, например, IDE Eclipse - просто чтобы не показывались warnings, кто любит "чистоту и порядок" - материал статьи и пример кода - за 2002 г., но это - мелочи).
Да, там в ведении к статье - расскажут, что принцип похож, в чем-то - на одну особенность программирования GUI в Windows.
Не пугайтесь, сейчас все расскажу. :) В Windows, после инициализации окна приложения, в которое вы хотите поместить контроллы (элементы управления) - используется следующая схема - операционная система направляет все события для этого окна - в компонент этого окна, причем события (сворачивания окна, например) - идут "очередью" и ваша задача - "присосаться" к этой очереди и отбирать нужные вам события (обрабатывать их).
Примерно по такому же принципу построено и данное решение программирования многопоточного сокет-сервера. Дело в том, что используя только одну многопоточность - вы будете блокироваться на входящем потоке сообщений, поступающих на ваш сокет-сервер. Пакет же nio - позволит вам установить неблокирующую обработку этих сообщений (а так же прерывание других, параллельных потоков обработки, обслуживающих подключения других клиентов к этому сокет-серверу).
Под конец объяснения в этой статье - становится не совсем понятно. И даже пример с кодом - может вас не раз заставить почесать вашу (умную) головушку. На мой взгляд здесь объяснение такое - часть решения - инкапсулировано в пакете nio. Поэтому вы не видите всех "хвостиков" его.
Но если в двух словах (там еще упоминается паттерн проектирования Reactor) - то объяснение лучшей (или одной из лучших) практик - я вам уже пересказал. :)
К сожалению - материал на английском, на сайте IBM.
Материал очень хорошо оформлен, есть поясняющие UML-диаграммы, показывающие зависимости используемых интерфейсов.
Можно скачать пример с кодом (чуть-чуть его придется подпилить, в сущих пустяках, которые покажет вам, например, IDE Eclipse - просто чтобы не показывались warnings, кто любит "чистоту и порядок" - материал статьи и пример кода - за 2002 г., но это - мелочи).
Да, там в ведении к статье - расскажут, что принцип похож, в чем-то - на одну особенность программирования GUI в Windows.
Не пугайтесь, сейчас все расскажу. :) В Windows, после инициализации окна приложения, в которое вы хотите поместить контроллы (элементы управления) - используется следующая схема - операционная система направляет все события для этого окна - в компонент этого окна, причем события (сворачивания окна, например) - идут "очередью" и ваша задача - "присосаться" к этой очереди и отбирать нужные вам события (обрабатывать их).
Примерно по такому же принципу построено и данное решение программирования многопоточного сокет-сервера. Дело в том, что используя только одну многопоточность - вы будете блокироваться на входящем потоке сообщений, поступающих на ваш сокет-сервер. Пакет же nio - позволит вам установить неблокирующую обработку этих сообщений (а так же прерывание других, параллельных потоков обработки, обслуживающих подключения других клиентов к этому сокет-серверу).
Под конец объяснения в этой статье - становится не совсем понятно. И даже пример с кодом - может вас не раз заставить почесать вашу (умную) головушку. На мой взгляд здесь объяснение такое - часть решения - инкапсулировано в пакете nio. Поэтому вы не видите всех "хвостиков" его.
Но если в двух словах (там еще упоминается паттерн проектирования Reactor) - то объяснение лучшей (или одной из лучших) практик - я вам уже пересказал. :)
Многопоточность. Функциональное программирование. Состояния
Если вы читали мою критику на счет функционального программирования (Часть 1 и Часть 2), тогда попробуем проанализировать один момент.
Функциональное программирования (далее - ФП) не всегда "работает в 2D-плоскости", иногда людям хочется расширить, некоторые горизонты, по применяемым средствам. В частности это выражается в создании библиотек, имитирующих работу с объектами, и в создании некоторых паттернов, где функцией пытаются оперировать как объектом...
И вот, наступает такой момент, для таких "продвинутых" товарищей, когда в ФП приходится иметь дело с состояниями.Тут сразу теряется все хваленое преимущество при работе с многопоточностью, ведь как раз отсутствие состояний у объектов - в мире ФП - как раз и позволяло им говорить о некоторых преимуществах.
Небольшое отступление. Далее будут упомянуты 2 ссылки, на видео, все на английском, поэтому хорошо знающим английский язык - лучше просто посмотреть их, и прочитать краткие пояснения к ним, там же (Ссылка 3, Ссылка 4).
Если же лениво, и вы хотите довольствоваться моим "обгрызанием" темы, с моим техническим английским, с которым я эти видео-демонстрации не смотрел, а вынужден довольствоваться только английским текстом рядом с ними - тогда можете оставаться. :)
Кстати, обращаю внимание тех, кто знает английский лишь на уровне технического - в упомянутой уже Ссылке 3 - текста (английского) - кот наплакал, поэтому все-таки кликните. Ну в самом деле там крохи того текста.
А вот в упомянутой Ссылке 4 - английского текста много, но он читается совершенно легко, для тех кто знает только технический английский (надеюсь данная ссылка имеет отношение к предыдущей, мне показалось что имеет).
Выделим характерную цитату из упомянутой Ссылки 3:
"When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs."
И после этого "приложим" сюда рассказ про "реактивный" ФП-фреймворк из упомянутой Ссылки 4.
Что же получается? (с поправкой на то, что сами видеоматериалы лично я не смотрел)
Получается примерно такая картина - когда в ФП приходится иметь с состояниями - то решение сводится к транзакционной памяти, которую введут в .NET 4 (заимствование идеи из мира СУБД - фиксация удачной операции, если другой поток не внес изменения; сама идея еще прорабатывается, хотя для желающих уже доступна версия для скачивания), а так же - к использованию событий (куда, каким-то хорошим боком, относится всем известный паттерн Observer из GoF).
В общем-то все, что я хотел сказать...
Функциональное программирования (далее - ФП) не всегда "работает в 2D-плоскости", иногда людям хочется расширить, некоторые горизонты, по применяемым средствам. В частности это выражается в создании библиотек, имитирующих работу с объектами, и в создании некоторых паттернов, где функцией пытаются оперировать как объектом...
И вот, наступает такой момент, для таких "продвинутых" товарищей, когда в ФП приходится иметь дело с состояниями.Тут сразу теряется все хваленое преимущество при работе с многопоточностью, ведь как раз отсутствие состояний у объектов - в мире ФП - как раз и позволяло им говорить о некоторых преимуществах.
Небольшое отступление. Далее будут упомянуты 2 ссылки, на видео, все на английском, поэтому хорошо знающим английский язык - лучше просто посмотреть их, и прочитать краткие пояснения к ним, там же (Ссылка 3, Ссылка 4).
Если же лениво, и вы хотите довольствоваться моим "обгрызанием" темы, с моим техническим английским, с которым я эти видео-демонстрации не смотрел, а вынужден довольствоваться только английским текстом рядом с ними - тогда можете оставаться. :)
Кстати, обращаю внимание тех, кто знает английский лишь на уровне технического - в упомянутой уже Ссылке 3 - текста (английского) - кот наплакал, поэтому все-таки кликните. Ну в самом деле там крохи того текста.
А вот в упомянутой Ссылке 4 - английского текста много, но он читается совершенно легко, для тех кто знает только технический английский (надеюсь данная ссылка имеет отношение к предыдущей, мне показалось что имеет).
Выделим характерную цитату из упомянутой Ссылки 3:
"When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs."
И после этого "приложим" сюда рассказ про "реактивный" ФП-фреймворк из упомянутой Ссылки 4.
Что же получается? (с поправкой на то, что сами видеоматериалы лично я не смотрел)
Получается примерно такая картина - когда в ФП приходится иметь с состояниями - то решение сводится к транзакционной памяти, которую введут в .NET 4 (заимствование идеи из мира СУБД - фиксация удачной операции, если другой поток не внес изменения; сама идея еще прорабатывается, хотя для желающих уже доступна версия для скачивания), а так же - к использованию событий (куда, каким-то хорошим боком, относится всем известный паттерн Observer из GoF).
В общем-то все, что я хотел сказать...
Еще одна экспериментальная ОС от Microsoft
Текст новости здесь.
Цитата: "Helios - это операционная система, предназначенная для упрощения задачи подготовки, развертывания и настройки приложений для гетерогенных платформ. В Helios введены вспомогательные ядра, которые экспортируют единообразный набор абстракций ОС для процессоров различных архитектур и с разными характеристиками производительности. Доступ к системе ввода/вывода, например файловой системе, прозрачен и осуществляется через удаленную передачу сообщений, которая расширяет абстракцию передачи сообщений между микроядрами до инфраструктуры вспомогательных микроядер. Helios перенаправляет приложение на доступные шины ISA путем компиляции кода из промежуточного языка".
Еще одна ссылка - "Barrelfish и Windows 8".
Цитата: "Напомню, что проект Singularity, начатый в далеком 2003 году, подразумевал создание высоконадежной ОС, в основе которой лежит идея использования программно-изолированных процессов (Software Isolated Processes, SIP), общение между которыми происходит посредством сообщений."
Цитата: "Helios - это операционная система, предназначенная для упрощения задачи подготовки, развертывания и настройки приложений для гетерогенных платформ. В Helios введены вспомогательные ядра, которые экспортируют единообразный набор абстракций ОС для процессоров различных архитектур и с разными характеристиками производительности. Доступ к системе ввода/вывода, например файловой системе, прозрачен и осуществляется через удаленную передачу сообщений, которая расширяет абстракцию передачи сообщений между микроядрами до инфраструктуры вспомогательных микроядер. Helios перенаправляет приложение на доступные шины ISA путем компиляции кода из промежуточного языка".
Еще одна ссылка - "Barrelfish и Windows 8".
Цитата: "Напомню, что проект Singularity, начатый в далеком 2003 году, подразумевал создание высоконадежной ОС, в основе которой лежит идея использования программно-изолированных процессов (Software Isolated Processes, SIP), общение между которыми происходит посредством сообщений."
Новая ОС от Microsoft с приоритетом на многоядерность
Новость можно прочитать здесь.
Цитата: "... вместо того, чтобы полностью изолировать программу от оборудования с помощью драйвера, в Barrelfish есть своего рода база данных, в которой хранится низкоуровневая информация об оборудовании. Ядро системы однопоточно и непрерывно. Планирование происходит одновременно с передачей сообщений, а получение сообщения просто активирует поток ожидания. В ОС также используются концепты микроядер, согласно которой драйвера выполняются в защищенной среде, например в L4."
- Похоже, что многопоточность реализуется по "правилу одного потока", которое следует применять при использовании Swing.
В Swing есть очередь выполнения, и есть диспетчер событий этой очереди. К этому диспетчеру событий мы можем обратиться из любого потока. Диспетчер событий просто поставит в очередь то действие, которое вы хотите чтобы оно выполнилось. Никаких обращений к компонентам Swing (хотя есть исключения, в частности некоторые read-свойства можно использовать) - только через этот диспетчер.
После постановки вашего действия в очередь событий, вы можете как "заблокироваться" на этом (дождаться выполнения, выполнение ведь, по своему характеру - является отложенным), а можете и асинхронно - выполнять что-то либо в программе, предполагая что в Swing-е со временем что-то изменится, то что вам нужно (иногда это очень удобно, например вы постоянно "пингуете" эту очередь, добавляя туда, например, новые данные индикации загрузки - на сколько система будет успевать - она будет изображать вашу индикацию загрузки).
Пример кода:
/* Без блокировки.
* Если нужно с блокировкой, т.е. дождаться выполнения,
* то используем метод EventQueue.invokeAndWait(...)
*/
EventQueue.invokeLater
(
new Runnable()
{
public void run()
{
label.setText(percentage+"% выполнено");
}
}
);
Новая ОС, в дополнении к этому, по видимому применяет аналог транзакционной памяти, которую вводят в .NET 4.
В заключении скажу, что в J2SE 6 - добавили разработанный одним из программистов класс SwingWorker, который капельку упрощает пример, описанный выше (инкапсулирование + паттерн Template Method - проще говоря вам предоставляется метод для реализации задачи, и механизм для запуска всего).
Ну авсе остальное вы найдете, как всегда, в Интернете прочитать более подробно можно в постоянно упоминаемой мною книге Хорстманна по J2SE 6 (в данном случае - в 1-ом томе ее).
Кому любопытно и кто кликнет по ссылке выше о книге - там уже появился в том числе и мой комментарий: :)
"Книга, конечно, хорошая, но объем 8-ого издания стал меньше на процентов 10%, чем в 7-ом издании (сравниваю по двум томам).
Опечаток больно много. Но, как написали ниже, все же не критично (но переводчику и корректору с большими ... ой, ушами - уши бы я открутил...) "
Цитата: "... вместо того, чтобы полностью изолировать программу от оборудования с помощью драйвера, в Barrelfish есть своего рода база данных, в которой хранится низкоуровневая информация об оборудовании. Ядро системы однопоточно и непрерывно. Планирование происходит одновременно с передачей сообщений, а получение сообщения просто активирует поток ожидания. В ОС также используются концепты микроядер, согласно которой драйвера выполняются в защищенной среде, например в L4."
- Похоже, что многопоточность реализуется по "правилу одного потока", которое следует применять при использовании Swing.
В Swing есть очередь выполнения, и есть диспетчер событий этой очереди. К этому диспетчеру событий мы можем обратиться из любого потока. Диспетчер событий просто поставит в очередь то действие, которое вы хотите чтобы оно выполнилось. Никаких обращений к компонентам Swing (хотя есть исключения, в частности некоторые read-свойства можно использовать) - только через этот диспетчер.
После постановки вашего действия в очередь событий, вы можете как "заблокироваться" на этом (дождаться выполнения, выполнение ведь, по своему характеру - является отложенным), а можете и асинхронно - выполнять что-то либо в программе, предполагая что в Swing-е со временем что-то изменится, то что вам нужно (иногда это очень удобно, например вы постоянно "пингуете" эту очередь, добавляя туда, например, новые данные индикации загрузки - на сколько система будет успевать - она будет изображать вашу индикацию загрузки).
Пример кода:
/* Без блокировки.
* Если нужно с блокировкой, т.е. дождаться выполнения,
* то используем метод EventQueue.invokeAndWait(...)
*/
EventQueue.invokeLater
(
new Runnable()
{
public void run()
{
label.setText(percentage+"% выполнено");
}
}
);
Новая ОС, в дополнении к этому, по видимому применяет аналог транзакционной памяти, которую вводят в .NET 4.
В заключении скажу, что в J2SE 6 - добавили разработанный одним из программистов класс SwingWorker, который капельку упрощает пример, описанный выше (инкапсулирование + паттерн Template Method - проще говоря вам предоставляется метод для реализации задачи, и механизм для запуска всего).
Ну а
Кому любопытно и кто кликнет по ссылке выше о книге - там уже появился в том числе и мой комментарий: :)
"Книга, конечно, хорошая, но объем 8-ого издания стал меньше на процентов 10%, чем в 7-ом издании (сравниваю по двум томам).
Опечаток больно много. Но, как написали ниже, все же не критично (но переводчику и корректору с большими ... ой, ушами - уши бы я открутил...) "
Parallel-Ax и Кей Хорстманн
Кей Хорстманн (Cay Horstmann) получил большую известность в мире Java-разработчиков благодаря своей книге по J2SE (Том 1 и Том 2), написанной им в соавторстве с Гари Корнеллом (Gary Cornell). Книга выдержала уже 8 изданий и до сих пор является одной из лучших.
Можно отметить и другую книгу, написанную Хорстманном (в соавторстве с другим автором) - "JavaServer Faces", но разговор сейчас не о ней.
В 8-ом издании вышеозначенной книги по J2SE - наткнулся на интересный момент в описании многопоточности (не поленился, открыл 7-ое издание - не так понятно этот момент описан), цитата (стр. 763 русского издания):
"Блокирующие очереди.
Теперь вы знакомы со всеми низкоуровневыми строительными блоками, формирующими основы параллельного программирования в Java. Однако в практическом программировании вы предпочтете держаться насколько возможно, дальше от низкоуровневых конструкций. Гораздо проще и безопаснее работать со структурами более высокого уровня, реализованными экспертами в области параллелизма.
Многие проблемы, связанные с потоками, можно элегантно и безопасно сформулировать, применив одну или более очередей. Поток-поставщик вставляет элементы в очередь, а потоки-потребители извлекают их. Очередь позволяет безопасно передавать данные из одного потока в другой. ..."
- Другими словами речь идет о том, что с помощью ООП - можно решить большинство проблем, связанных с многопоточностью. Один из главных принципов - потоки обмениваются сообщениями (как у меня описано), ну а для реализации отправки сообщений - можно, часто, воспользоваться очередями сообщений (а вот тут можно дистанцироваться от конкретного поставщика, который предоставляет такие очереди и сервис по ним - например ребята из JBoss Community используют такие крайне правильные принципы в своих разработках). В контексте цитаты из книги - блокирующие очереди являются одним из решений (решения под конкретные задачи - могут быть и не c блокирующими очередями).
Я не придумал какие-то фундаментальные принципы, более того - в описании моей архитектуры Parallel-Ax указана, в разделе "Литература", - одна из отличнейших книг по архитектурам систем, основанных на обмене сообщениями.
Мне просто показалось странным, что люди упираются в какие-то "ворота", представляя все в "плоском 2D-измерении" (это имеет смысл при какой-то оптимизации процесса).
Вот я "взял и придумал", конкретное архитектурное решение.
ООП снимает покров мистической чудодейственной силы, приписываемой ФП, :) а теперь и (Хорстманну вы наверняка поверите больше, чем мне) убирает большинство проблем, связанных с многопоточностью.
Можно отметить и другую книгу, написанную Хорстманном (в соавторстве с другим автором) - "JavaServer Faces", но разговор сейчас не о ней.
В 8-ом издании вышеозначенной книги по J2SE - наткнулся на интересный момент в описании многопоточности (не поленился, открыл 7-ое издание - не так понятно этот момент описан), цитата (стр. 763 русского издания):
"Блокирующие очереди.
Теперь вы знакомы со всеми низкоуровневыми строительными блоками, формирующими основы параллельного программирования в Java. Однако в практическом программировании вы предпочтете держаться насколько возможно, дальше от низкоуровневых конструкций. Гораздо проще и безопаснее работать со структурами более высокого уровня, реализованными экспертами в области параллелизма.
Многие проблемы, связанные с потоками, можно элегантно и безопасно сформулировать, применив одну или более очередей. Поток-поставщик вставляет элементы в очередь, а потоки-потребители извлекают их. Очередь позволяет безопасно передавать данные из одного потока в другой. ..."
- Другими словами речь идет о том, что с помощью ООП - можно решить большинство проблем, связанных с многопоточностью. Один из главных принципов - потоки обмениваются сообщениями (как у меня описано), ну а для реализации отправки сообщений - можно, часто, воспользоваться очередями сообщений (а вот тут можно дистанцироваться от конкретного поставщика, который предоставляет такие очереди и сервис по ним - например ребята из JBoss Community используют такие крайне правильные принципы в своих разработках). В контексте цитаты из книги - блокирующие очереди являются одним из решений (решения под конкретные задачи - могут быть и не c блокирующими очередями).
Я не придумал какие-то фундаментальные принципы, более того - в описании моей архитектуры Parallel-Ax указана, в разделе "Литература", - одна из отличнейших книг по архитектурам систем, основанных на обмене сообщениями.
Мне просто показалось странным, что люди упираются в какие-то "ворота", представляя все в "плоском 2D-измерении" (это имеет смысл при какой-то оптимизации процесса).
Вот я "взял и придумал", конкретное архитектурное решение.
ООП снимает покров мистической чудодейственной силы, приписываемой ФП, :) а теперь и (Хорстманну вы наверняка поверите больше, чем мне) убирает большинство проблем, связанных с многопоточностью.
Parallel-Ax
Логическим продолжением цикла статей-обсуждений "Многопоточность - проще не бывает" - стала "консолидация" всего материала и описание его в Викизнаниях.
Ссылка на Parallel-Ax.
UPD 1. Смотри также "Parallel-Ax и Кей Хорстманн".
Ссылка на Parallel-Ax.
UPD 1. Смотри также "Parallel-Ax и Кей Хорстманн".
Многопоточность - проще не бывает 3.
(Начало статьи - смотрите в 1-ой части и во 2-ой части).
Другими словами, та проблема, которая перед нами стоит - это как эффективно использовать многоядерность процессоров и потоков данных. Потому что тактовые частоты процессоров уже почти не получается увеличивать, на данный день, чтобы обспечить этим основной прирост производительности. Вот я и предлагаю - перейти к асинхронной модели программирования на потоках. Взаимодействие между которыми - событийное. Это сразу решает большинство проблем, связанных с многопоточностью. Да и... а как оно в жизни то - один программист - прочитал 1 учебник за год, другое - 4 учебника. - Конечно их пути развития - асинхронны, их нельзя свести к одинаковой величине через год. И что нам тут мешает? - Да практически ничего. Организуем ветки, петли выполнения программ, на каждом потоке. Включая и то, что, популярное нынче "низкрогранулированное" "решение" построения фреймворков - представляет собой набор подсистем. Почему каждая из подсистем - не может "крутиться" в своем потоке, вот вы мне скажите? При событийной модели (и такие примеры, отличнейшие, правда пока без такой многопоточности) - уже есть - взять фреймворк JBoss Seam. - Типичнейший пример, с отличной системой генерации событий и "низкогранурированностью".
Значит проблемы нет? Раз уже есть "подходящие" фреймворки, которые могут задействовать сотни потоков одновременно.
Вы хотите сказать, что есть, например, такие высоконагруженные операции, как вывод графики, и как же тогда там? Что значит - "высоконагруженные операции графики" - вы ДЕКОМПОЗИРУЙТЕ задачу. На сотню отдельных составляющих. Каждая из которых будет крутиться в своем потоке. Нужно отрендерить "задний план", на картинке? - Пускай это сделает отдельный подузел. Если у нас есть 50 потоков для рендеринга заднего плана - декомпозируйте еще. Вплоть до обсчета 2x2 пикселя в левом верхнем углу одним из них.
Вы хотите сказать - а как же эффекты, как же - текстуры, накладываемые после, как же - шейдеры? - Блин, ну а как же организован конвейер на любом заводе? Есть 10-100 автоматов, каждый из которых - "существует в отдельном потоке" (в свою очередь каждый такой автомат - может состоять из еще - множества различных узлов его).
Какие-то операции, как делается сейчас - могут выполняться более-менее параллельно - например нам нужно 4 конвейера для выпуска одной легковой машины.
А если нужно преобразовать какой-то сигнал, то можно поделить его рабочую частоту - на кол-во доступных потоков, чтобы каждый "обсчитывал" свою часть.
Первое правило - декомпозиция, как метод борьбы со сложностью. Ну и запускайте каждый "декомпозированный" элемент - в отдельном потоке. Если у нас может быть, иногда, 25 потоков, для какой-то подсистемы, доступно, а может быть что и 450 потоков будет доступно (на каком-то там готовящемся к выходу процессоре) - пожалуйста - заложите в конструкцию, что если 25 потоков - то Система декомпозируется на 12 подсистем + еще 13 потоков можно "передать" на декомпозицию некоторым из них. Если у нас 450 потоков - тогда 12 подсистем (на деле, каждая из которых еще декомпозируется на сотни более мелких) - большинство из них получат свои потоки.
Тут уже и архитектура вырисовывается... новых фреймворков...
Другими словами, та проблема, которая перед нами стоит - это как эффективно использовать многоядерность процессоров и потоков данных. Потому что тактовые частоты процессоров уже почти не получается увеличивать, на данный день, чтобы обспечить этим основной прирост производительности. Вот я и предлагаю - перейти к асинхронной модели программирования на потоках. Взаимодействие между которыми - событийное. Это сразу решает большинство проблем, связанных с многопоточностью. Да и... а как оно в жизни то - один программист - прочитал 1 учебник за год, другое - 4 учебника. - Конечно их пути развития - асинхронны, их нельзя свести к одинаковой величине через год. И что нам тут мешает? - Да практически ничего. Организуем ветки, петли выполнения программ, на каждом потоке. Включая и то, что, популярное нынче "низкрогранулированное" "решение" построения фреймворков - представляет собой набор подсистем. Почему каждая из подсистем - не может "крутиться" в своем потоке, вот вы мне скажите? При событийной модели (и такие примеры, отличнейшие, правда пока без такой многопоточности) - уже есть - взять фреймворк JBoss Seam. - Типичнейший пример, с отличной системой генерации событий и "низкогранурированностью".
Значит проблемы нет? Раз уже есть "подходящие" фреймворки, которые могут задействовать сотни потоков одновременно.
Вы хотите сказать, что есть, например, такие высоконагруженные операции, как вывод графики, и как же тогда там? Что значит - "высоконагруженные операции графики" - вы ДЕКОМПОЗИРУЙТЕ задачу. На сотню отдельных составляющих. Каждая из которых будет крутиться в своем потоке. Нужно отрендерить "задний план", на картинке? - Пускай это сделает отдельный подузел. Если у нас есть 50 потоков для рендеринга заднего плана - декомпозируйте еще. Вплоть до обсчета 2x2 пикселя в левом верхнем углу одним из них.
Вы хотите сказать - а как же эффекты, как же - текстуры, накладываемые после, как же - шейдеры? - Блин, ну а как же организован конвейер на любом заводе? Есть 10-100 автоматов, каждый из которых - "существует в отдельном потоке" (в свою очередь каждый такой автомат - может состоять из еще - множества различных узлов его).
Какие-то операции, как делается сейчас - могут выполняться более-менее параллельно - например нам нужно 4 конвейера для выпуска одной легковой машины.
А если нужно преобразовать какой-то сигнал, то можно поделить его рабочую частоту - на кол-во доступных потоков, чтобы каждый "обсчитывал" свою часть.
Первое правило - декомпозиция, как метод борьбы со сложностью. Ну и запускайте каждый "декомпозированный" элемент - в отдельном потоке. Если у нас может быть, иногда, 25 потоков, для какой-то подсистемы, доступно, а может быть что и 450 потоков будет доступно (на каком-то там готовящемся к выходу процессоре) - пожалуйста - заложите в конструкцию, что если 25 потоков - то Система декомпозируется на 12 подсистем + еще 13 потоков можно "передать" на декомпозицию некоторым из них. Если у нас 450 потоков - тогда 12 подсистем (на деле, каждая из которых еще декомпозируется на сотни более мелких) - большинство из них получат свои потоки.
Тут уже и архитектура вырисовывается... новых фреймворков...
Подписаться на:
Сообщения (Atom)