Инь и ян программирования или alter ego многопоточности

Происходит вполне осязаемый процесс зомбирования многопоточностью. А потому хотелось бы кое-что уточнить, конкретизировать, что можно считать параллельными вычислениями и, соответственно, параллельным программированием, а что нельзя.

 Предположим, перед вами «черный ящик». Это может быть, к примеру, ваш комп , ноут или хотя бы смартфон. Нет внешних критериев, по которым вы могли бы идентифицировать алгоритм его работы. В смысле параллельный он или последовательный. Следовательно, для любой последовательной программы должен быть универсальный формальный механизм, преобразующий ее в эквивалентную параллельную программу и наоборот.

 Уже давно известны универсальные модели последовательных алгоритмов, такие как машина Тьюринга или машина Поста. Есть и другие модели, но без потери общности вполне можно ограничиться упомянутыми. Но современный собеседник буквально впадает в ступор, когда речь заходит о  модели параллельных вычислений.

Но так было не всегда. В 80-х годах прошлого века математики, программисты и другие, причастные к процессу алгоритмизации и программирования, пытались такую модель создать. К сожалению, все, похоже, завершилось автоматом сетями Петри. Но даже с учетом столь печального факта, как не успешность таких поисков, должна существовать, как и в случае последовательных алгоритмов, модель параллельных алгоритмов. Без нее разговоры об упомянутом выше  преобразовании алгоритмов просто не имеют смысла.

В силу философского закона единства и борьбы  противоположностей, когда есть одно, то должно быть и другое. Так, если есть свет, то, как ни крути, будет и тьма. Когда есть хорошее, то рано или поздно, как ни избегай, будет и плохое (жизнь, как известно, в полоску). А если есть последовательное программирование, то должно быть, как его ни назови, альтернативное ему - параллельное. А если уж оно есть или, как минимум, обсуждается, то необходимо дать ему определение, аналогичное по смыслу моделями обычных алгоритмов. Все это естественно и даже очевидно, когда речь идет о научных понятиях и, как в нашем случае, о науке программирования.

Современная многопоточность это alter ego допотопного последовательного  программирования. Одновременно она пример антинаучности и чего-то такого с неопределяемой сущностью. Именно этим можно объяснить весь негатив в ее адрес, подкрепленный яркими описаниями ее сложности и множества проблем (см. хотя бы [1] ^[1]). При наличии определения это все подкреплялось бы научной точкой зрения. Было бы, безусловно, по-прежнему печально, но хотя бы печаль эта была обоснованной. А так остается только смириться. И многие смиряются. Более того, часто даже агрессивно реагируют, сталкиваясь с альтернативой. С, так сказать, alter ego  уже многопоточности.

Параллельно автоматное программирование (АП) это и есть настоящее alter ego последовательного программирования. Не интуитивно понимаемое, а научно обоснованное[2] ^[2]. Порукой тому существующая теория АП и достаточно простые процедуры, которые позволяют однозначно для любой последовательной программы построить эквивалентную параллельную программу. Определены и обратные процедуры, не всегда однозначные, но, главное, эквивалентные. Таким образом, все согласуется  с интуитивными представлениями об алгоритмическом  «черном ящике», описанном нами вначале.

Утверждать, что многопоточность представляет параллельное программирование, все равно что «ставить телегу впереди лошади». Без формальных определений и доказательств рано говорить о подобной модели параллелизма. Именно это игнорируется, порождая тем самым  множество проблем современного параллелизма, как в понимании, так и в применении.

Именно на модель параллельных алгоритмов и только на нее должно опираться определение и/или реализация языка параллельного программирования. Пока же многопоточность буквально втискивают в языки программирования. Порой, это повод для создания нового языка программирования. А, если он параллельный, то почти обязан наследовать многопоточность. Сформировалась крепкая связка - «параллелизм = многопоточность».

Не рано ли? Рано, т.к. в силу рассмотренных причин необоснованно усложняет языки программирования, делая их весьма громоздкими. Создается ложное представление о некой их «новизне». Куда спешим? Ведь, хорошо известны подходы, позволяющие  использовать язык программирования в любой его ипостаси, не плодя при этом новые параллельные версии. 

Автоматное программирование – не просто альтернатива многопоточности. Это научно обоснованная модель параллельных вычислений. Это, кто и что не говорил бы, «медицинский факт». О многопоточности так сказать нельзя. АП можно критиковать, с чем-то не соглашаться, можно, в конце концов, не использовать совсем, но нельзя игнорировать, отмахнуться. То, что доказано формальным путем, может быть аннигилировано лишь таким же путем.

А есть ли уже сейчас что-то близкое по возможностям к АП? Есть. Например, все, что связано с диаграммами Харела (State-chart) и языком UML. Это походы родственные АП, но все же несколько отличающиеся от него. Обидно, что не в лучшую сторону. Особенно, что касается описания и реализации параллелизма. Да и модель автомата Харела, если уж вникать в детали, здесь другая.

МАТЛАБ – наиболее известная среда проектирования, поддерживающая автоматную модель программирования Харела. После всех ограничений она конвертировалась у нас в среду Engee. Средой, поддерживающей аналогичные автоматы, является и среда SimInTech – наш ответ МАТЛАБ-у и конкурент Engee. Хотя, прямо скажем, реализация автоматов в ней весьма своеобразна.

Подведем итог. Под многопоточностью научной базы нет. Из-за этого ее будущность весьма туманна. И туману этому – ой! - уже сколько лет! Остерегайтесь процессов зомбирования. Пусть даже многопоточностью.

Литература

1.       Три способа менять один объект из нескольких потоков. Больше нет ^[3]. https://habr.com/ru/articles/974198/ ^[3]

2.       Искусство выжить. Простое руководство для настоящих программистов ^[2]. https://habr.com/ru/articles/969036/ ^[2]

ttps://habr.com/ru/articles/969036/ ^[2]