Если вы сравниваете производительность программ так и сравнивайте производительность программ, а не языки программирования.
Я сказал "серсер". Т.е. нечто иное чем Вы перечислили. О чем Вы?
О том, что в 1990-е для подавляющего большинства программистов знания о "серверах" были чуть менее чем бесполезны. А для многих это и сейчас так. Что не мешает им решать сложные задачи.
Т.е. отдельная х64 не в состоянии даже выполнять один программный сервер, например, базу данных.
Точно уверены? Вот точно-точно? Хоть бы параметры этой самой "базы данных" озвучили...
Их запрягают десятками, сотнями, тысячами в одну упряжку.
И десятками тысяч. Что в итоге дает горизонтальное масштабирование такой величины и за такую небольшую цену, что МФ от IBM, предполагаю, и не снилась.
Но мы уходим от темы, а именно -- программисты из 90-х занимаясь варворством на дохлых PC-ках довели ситуацию до того, то МФ от IBM на общих масштабах нужно разглядывать в микроскоп. Да, где-то они все еще рулят и педалят, но погоды не делают. Т.е. прогрессом их вынесло на обочину. Ну и зачем, спрашивается, программистам из 90-х нужно было на эти самые МФ оглядываться с придыханием? Вопрос риторический.
х64 это кирпичи в стене здания, а МФ это здание. Так понятнее?
Нет.
Т.е. с Вашей точки зрения программиста С++ между Windows и OS/2 нет разницы. Тогда почему же: "OS/2 ничего не светит, было понятно еще в 1994-ом".
Потому что руководители направления OS/2 из IBM не бегали по сцене и не кричали "Developers, Developers, Developers!!!" А Балмер бегал и кричал. И MS привлекли такое количество разработчиков под Windows, что OS/2 нечего было ловить.
Конечным потребителям была совершенно фиолетова техническая совершенность потрохов OS/2. Им нужен был полезный софт, а полезный софт массово писали под Windows, а не под OS/2. Именно это и похоронило OS/2. И это мне лично было понятно еще в 1994-ом.
Я согласен с тем что во многом (опять же с точки зрения пользователя) NT в начале 2000-х в общем сравнялся с OS/2
В начале 2000-х OS/2 была уже никому (даже IBM) ненужным ископаемым. NT стала хорошей системой еще в середине 1990-х и OS/2 выигрывала лишь тем, что могла лучше работать на машинах с относительно дохлыми процессорами и 8Mb RAM. Но уже на 16Mb, не говоря уже про 32Mb, разницы не было. Т.е. технический прогресс и этот аргумент из под ног OS/2 выбил.
Я считаю что они бы полностью сранялись потому что на х86-64 есть вполне досигаемый предел развития ОС и он уже давно достигнут. Уже давно новые версии Windows это лишь новый интефейс
Судить по возможностях современных x86-64 по Windows -- это не менее мощно, чем судить о Java по производительности программ на Java в конце 1990-х.
Поделиться своим пониманием программирования под Windows и под OS/2?
Из того, что запомнилось до сих пор:
В Windows (как и до этого в MS-DOS, как и в X-ах, если не ошибаюсь) отсчет координат шел от верхнего левого угла экрана (и от верхнего левого угла текущего окна). А вот в OS/2 Presentation Manager -- от левого нижнего. Т.е. в OS/2 PM координаты x и y шли как в школьной геометрии. Что, однако, при выводе текста на русском языке или при рисовании в окне технологических схем/чертежей, оказывалось менее удобно -- мы то читаем слева направо и сверху вниз, логично было бы и координаты в таком же направлении отсчитывать. Но в OS/2 PM нужно было делать дополнительный пересчет;
в OS/2 PM была плохая "привычка" не создавать окна, если программист ошибся с перечислением ресурсов окна. Например, для фрейма (вроде бы так в OS/2 PM называлось окно с заголовком, иконкой и меню) нужно было задать ID для меню и для иконки. И если программист по недосмотру какой-то из этих ресурсов в ресурсном файле не определил, то фрейм просто не создавался без какой-то внятной диагностики. А найти такую ошибку, особенно по первости, было непросто. Это когда уже шишки были набиты возникла привычка проверять содержимое ресурсного файла и такие ошибки стало искать проще. Но вот под Windows такой проблемы не было -- даже если ID иконки или меню оказался неправильным, окно все равно создавалось, просто чего-то в нем не хватало и ты сразу видел чего именно. Плюс к тому, в Windows не было деления окон на фреймы и не фреймы, что мне казалось более логичным, чем подход из Presentation Manager.
Если бы Вы читали меня внимательно, то я писал что оценивал Java как пользователь продуктов изначально написанных на SmallTalk и потом переписанных на Java.
Т.е. вы, как пользователь программ на Java, оцениваете возможности Java как языка программирования. Мощно, внушаить!
Да не писал.
Ну вот я не писал програм ни на C#, ни на Haskell. Так я и не рассуждаю на тему того, что они каким-то другим языкам уступают или нет.
Тому каким должен быть сервер.
К программированию это относится косвенным образом. Не говоря уже о том, что для большого числа предметных областей (embedded, desktop, mobile, web front-end) это понимание не нужно чуть меньше чем совсем.
Сервер на персоналке это нонсен что понятно даже из слов.
Особенно смешно это звучит сейчас, когда (наверное) 99% серверов в Интернете крутятся на x64 серверах, являющихся прямыми наследниками IBM XT.
А что еще есть, например, в визуальном редакторе Visual Basic? Неужели все также "перетаскивание контролов на формочках "?
Понятия не имею, мой опыт программирования Visual Basic ограничивается VisualBasic for Application, в котором в то время визуального редактора не было. Но суть в том, что перетаскивание контролов -- это далеко не все, что есть в программировании. Да и когда мне доводилось заниматься GUI, то быстро выяснилось, что возюкание мышкой в дизайнере форм не самый удобный способ это делать (по крайней мере в тех задачах, которые были).
Поделиться своим пониманием программирования под Windows и под OS/2?
"Понимания"? Что вы вкладываете в это слово в данном контексте?
В Windows был свой API, в OS/2 -- свой. Язык программирования и там, и там один и тот же, в моем случае C++, прикладные алгоритмы и структуры данных не зависили от ОС. Были свои нюансы в том в API и возможностях ОС (типа классов приоритетов для тредов и количества этих самых приоритетов), но это именно что нюансы.
Windows NT 3.51 .... was released on May 30, 1995
Не вижу противоречий. OS/2 Warp вышла раньше (чем NT 3.51) и, емнип, требовала меньше аппаратных ресурсов, чем тогдашние Windows NT (уже не помню какая там была актуальная нумерация, 3.5 или еще какая-то). При этом работала гораздо надежнее и стабильнее и обеспечивала реально многозадачную среду, в отличии от Windows 3.1/3.11. Но даже тогда было понятно, что не светит OS/2 потеснить Windows. А когда в 1995-ом у меня появилась возможность поработать и в Windows 95, и в NT 3.51, то это убеждение только подтвердилось, т.к. по надежности и уровню поддержки настоящей вытесняющей многозадачности NT если и уступала OS/2, то некритично.
Это была абсолютно невосприимчивая ни к чему, кроме того что ей удалось освоить, секта.
И это сказал персонаж, который позволяет себе оценивать ту же Java ни разу на ней не попрограммировав? Мощно, внушаить.
Может раскажите, чему такому можно было научиться на МФ, чему было нельзя было научиться на персоналках? У вас там, в мире IBM, какие-то другие алгоритмы, структуры данных и парадигмы программирования? Или для вас программирование -- это перетаскивание контролов на формочках в визуальном редакторе или автоматизация LotusNotes?
А о тех же OS/2
Я начал программировать под Windows в 1993-ем, а под OS/2 в 1995-ом. Имею представление. И то, что OS/2 ничего не светит, было понятно еще в 1994-ом, хотя OS/2 Warp была хороша, но не то, чтобы принципиально лучше WinNT 3.51. Когда же вышла WinNT 4.0 полуось уже можно было закапывать, она могла остаться (и оставалась, что характерно) только в совсем специфических нишах. Даже удивительно, что так долго продержалась.
Посему то, что вы тут изглагаете выглядит как "врет как очевидец".
Ну вы-то не промолчали и выдали статью, в которой выплеснули изрядное количество известной субстанции. А раз ваша статья (за исключением цитат из внешних источников) этой самой субстанцией и является, то почему бы и не озвучить свою оценку?
Кроме того, что вы наговорили откровенной ерунды про перспективы Windows и OS/2 в начале-середине 1990-х, так вы еще и умудрились назвать варварами поколение программистов. На фоне того поколение вы выглядите динозавром, которому повезло прожить свою жизнь в нише мейнфреймов.
А к чему имели доступ тогдашние начинающие "программисты"?
У нас в провинциальном универе были большая ЕС ЭВМ (1020 или еще какая не помню), какая-то средняя СМ-ка (но мы под нее не успели попрограммировать, только какими-то учебными программами за ней пользовались), Robotron 1715, ЕС 1840/1841, IBM XT и AT. Это 1990-1995-й годы. С 1994-го я уже работал в небогатой компании на 386-х и 486-х.
вся статья — как раз и есть развернутый ответ на вопрос "какое отношение это имеет к параллельности"
Да-да-да, статья дает настолько хороший ответ, что чередной читатель вынужден написать:
еще раз перечитал статью и все-таки из содержания статьи вообще не понял, как использование КА, и в частности вашей библиотеки, избавляет от параллелизма, а так же решает главную проблему обработки данных
Ну и вишенкой на торте:
Если после прочтения остались конкретные вопросы по реализации — задавайте, с удовольствием отвечу.
У меня лично не столько конкретный вопрос, сколько удивление на тему того, как можно подобный *овнокод выдавать за решение.
Даже ведущие компиляторы, уже начиная со стандарта 2017 (а по факту даже с 2011) не гарантируют полную совместимость со стандартом как по самому языку, так и по стандартной библиотеке.
Это моя реальность начиная с 1990-х годов, еще даже до принятия первого стандарта -- у каждого компилятора было свое подмножество (а в бородатых 90-х, порой, и нестандартное надмножество) C++.
Таков путь.
Прямое следствие того, что есть отдельно стандарт и есть несколько независимых вендоров компиляторов.
Если когда-нибудь все компиляторы кроме одного единственного помрут, ситуация и поменяется, может быть. Но пока этого не произошло, будет именно так.
Жить с этим можно. А страдают от такого, в основном, разработчики кросс-платформенных библиотек и кросс-платформенных приложений. Если же проект живет в рамках одной платформы и одного компилятора (а таких, как оказалось, немало), то и проблем особых нет.
Вместо ответа по существу Вы оскорбили меня и неизвестных мне студентов.
Ой как удобно: сперва наговорили кучу не относящихся к техническим вопросам слов о том, что я вам кого-то напоминаю, затем откровенно перешли на личности желая узнать кто перед вами, а когда вам ответили тем же в духе "а судьи кто?" вы стали играть обиженку.
На ваш технический вопрос, кстати говоря, бы дан ответ.
Моя работа и её качество — предмет оценки сообщества
Ну вот любой желающий может заглянуть в ваш VCPa и сделать для себя вывод стоит связываться с таким кодом или нет. Я для себя сделал.
ЗЫ. Можно развлечь себя рассматриванием, например, класса LConvStr и его реализации.
Когда пытаются размазывать или припирать, то нормальная реакция - дать адекватный ответ.
"Только та революция чего-нибудь стоит, которая умеет защищаться." Вы бы должны были бы помнить.
И тут начинается - от "а ты кто такой" до "а нас то за что?"...
Нет, в комментариях к вашим статьям начинается "коллеги, а не втирают ли нам какую-то дичь?"
Но мне хотелось бы понять с кем я говорю - с "охранником" или "начальником"?
Тут есть встречные вопросы: а хватит ли у вас мозгов и опыта разобраться в том, что вам пишут оппоненты? А то ведь по качеству текстов ваших статей и ваших комментариев есть серьезные вопросы по первому пункту, а исходные тексты вашего VCPa заставляют задуматься о том, а умеете ли вы программировать вообще. Студенты 3-го курса должны бы код лучше выдавать.
"Какую программу мы будем считать параллельной?"
Как минимум, утилизирующую одновременно больше одного вычислительного ядра. Более того, использующую доступные вычислительные ядра для сокращения общего времени выполнения задачи за счет распараллеливания выполняемых операций.
Блин, я вам ссылки на Wikipedia давал, где описывается, что есть parallel computing.
Или тут опять вопрос к вашему умственному развитию и опыту, раз вы написанное там не в состоянии понять?
А то вы приходите на уже накрытую поляну параллельного программирования со своей специфической темой конкурентности в однопоточном режиме и потом обижаетесь, почему вам напихивают полную панамку.
Причем вы не правы в очень важном моменте: из ваших статей не становится понятно, что вы путаете "паралелльность" с "конкурентностью". Это, в лучшем случае, выясняется в комментариях, когда вас начинают размазывать припирать к стенке конкретными вопросами.
Но оценка статьи «натуральным интеллектом» и комментарии к ней говорят буквально об обратном. На момент написания этих строк голосов за статью (https://habr.com/ru/articles/937448/) ровно ноль - три плюса и три минуса и масса «хейта».
Удивительно, что всего три минуса и так мало "хейта". Поскольку вы задекларировали решение "кошмара параллельности", а по факту предложили подход из категории "устранение перхоти путем отсечения головы": ваша библиотека тупо не может запускать код в параллель и принципиально отказывается использовать больше одного вычислительного ядра современных CPU. Т.е. ваше "лекарство" от "кошмаров параллельности" -- это полный отказ от той самой параллельности.
Что в современном мире, где рост вычислительной мощности уже давно идет за счет увеличения количества ядер, тогда как прозводительность на одно ядро растет все меньше и меньше.
хранил не сам поток, а ссылку на него и хотел сразу же при его завершении отчищать память по указателю
Оказывался в подобной ситуации. Мое решение было в том, что у приложения была отдельная фоновая нить, которая занималась подобной "чисткой". Когда нужно было дождаться завершения рабочего треда с последующим удалением связанного с тредом объекта, то этой фоновой нити отправлялось специальное сообщение с нужной информацией. Фоновая нить получала сообщение, делала join и дожидалась завершения рабочей нити, после чего удаляла нужный объект.
Да уж. Да уж. Да уж.
C++ и Eiffel вместе с ObjectPascal и Objective-C тихо офигевают в сторонке.
Если вы сравниваете производительность программ так и сравнивайте производительность программ, а не языки программирования.
О том, что в 1990-е для подавляющего большинства программистов знания о "серверах" были чуть менее чем бесполезны. А для многих это и сейчас так. Что не мешает им решать сложные задачи.
Точно уверены? Вот точно-точно? Хоть бы параметры этой самой "базы данных" озвучили...
И десятками тысяч. Что в итоге дает горизонтальное масштабирование такой величины и за такую небольшую цену, что МФ от IBM, предполагаю, и не снилась.
Но мы уходим от темы, а именно -- программисты из 90-х занимаясь варворством на дохлых PC-ках довели ситуацию до того, то МФ от IBM на общих масштабах нужно разглядывать в микроскоп. Да, где-то они все еще рулят и педалят, но погоды не делают. Т.е. прогрессом их вынесло на обочину. Ну и зачем, спрашивается, программистам из 90-х нужно было на эти самые МФ оглядываться с придыханием? Вопрос риторический.
Нет.
Потому что руководители направления OS/2 из IBM не бегали по сцене и не кричали "Developers, Developers, Developers!!!" А Балмер бегал и кричал. И MS привлекли такое количество разработчиков под Windows, что OS/2 нечего было ловить.
Конечным потребителям была совершенно фиолетова техническая совершенность потрохов OS/2. Им нужен был полезный софт, а полезный софт массово писали под Windows, а не под OS/2. Именно это и похоронило OS/2. И это мне лично было понятно еще в 1994-ом.
В начале 2000-х OS/2 была уже никому (даже IBM) ненужным ископаемым. NT стала хорошей системой еще в середине 1990-х и OS/2 выигрывала лишь тем, что могла лучше работать на машинах с относительно дохлыми процессорами и 8Mb RAM. Но уже на 16Mb, не говоря уже про 32Mb, разницы не было. Т.е. технический прогресс и этот аргумент из под ног OS/2 выбил.
Судить по возможностях современных x86-64 по Windows -- это не менее мощно, чем судить о Java по производительности программ на Java в конце 1990-х.
Из того, что запомнилось до сих пор:
В Windows (как и до этого в MS-DOS, как и в X-ах, если не ошибаюсь) отсчет координат шел от верхнего левого угла экрана (и от верхнего левого угла текущего окна). А вот в OS/2 Presentation Manager -- от левого нижнего. Т.е. в OS/2 PM координаты x и y шли как в школьной геометрии. Что, однако, при выводе текста на русском языке или при рисовании в окне технологических схем/чертежей, оказывалось менее удобно -- мы то читаем слева направо и сверху вниз, логично было бы и координаты в таком же направлении отсчитывать. Но в OS/2 PM нужно было делать дополнительный пересчет;
в OS/2 PM была плохая "привычка" не создавать окна, если программист ошибся с перечислением ресурсов окна. Например, для фрейма (вроде бы так в OS/2 PM называлось окно с заголовком, иконкой и меню) нужно было задать ID для меню и для иконки. И если программист по недосмотру какой-то из этих ресурсов в ресурсном файле не определил, то фрейм просто не создавался без какой-то внятной диагностики. А найти такую ошибку, особенно по первости, было непросто. Это когда уже шишки были набиты возникла привычка проверять содержимое ресурсного файла и такие ошибки стало искать проще. Но вот под Windows такой проблемы не было -- даже если ID иконки или меню оказался неправильным, окно все равно создавалось, просто чего-то в нем не хватало и ты сразу видел чего именно. Плюс к тому, в Windows не было деления окон на фреймы и не фреймы, что мне казалось более логичным, чем подход из Presentation Manager.
Т.е. вы, как пользователь программ на Java, оцениваете возможности Java как языка программирования. Мощно, внушаить!
Ну вот я не писал програм ни на C#, ни на Haskell. Так я и не рассуждаю на тему того, что они каким-то другим языкам уступают или нет.
К программированию это относится косвенным образом. Не говоря уже о том, что для большого числа предметных областей (embedded, desktop, mobile, web front-end) это понимание не нужно чуть меньше чем совсем.
Особенно смешно это звучит сейчас, когда (наверное) 99% серверов в Интернете крутятся на x64 серверах, являющихся прямыми наследниками IBM XT.
Понятия не имею, мой опыт программирования Visual Basic ограничивается VisualBasic for Application, в котором в то время визуального редактора не было. Но суть в том, что перетаскивание контролов -- это далеко не все, что есть в программировании. Да и когда мне доводилось заниматься GUI, то быстро выяснилось, что возюкание мышкой в дизайнере форм не самый удобный способ это делать (по крайней мере в тех задачах, которые были).
"Понимания"? Что вы вкладываете в это слово в данном контексте?
В Windows был свой API, в OS/2 -- свой. Язык программирования и там, и там один и тот же, в моем случае C++, прикладные алгоритмы и структуры данных не зависили от ОС. Были свои нюансы в том в API и возможностях ОС (типа классов приоритетов для тредов и количества этих самых приоритетов), но это именно что нюансы.
Не вижу противоречий. OS/2 Warp вышла раньше (чем NT 3.51) и, емнип, требовала меньше аппаратных ресурсов, чем тогдашние Windows NT (уже не помню какая там была актуальная нумерация, 3.5 или еще какая-то). При этом работала гораздо надежнее и стабильнее и обеспечивала реально многозадачную среду, в отличии от Windows 3.1/3.11. Но даже тогда было понятно, что не светит OS/2 потеснить Windows. А когда в 1995-ом у меня появилась возможность поработать и в Windows 95, и в NT 3.51, то это убеждение только подтвердилось, т.к. по надежности и уровню поддержки настоящей вытесняющей многозадачности NT если и уступала OS/2, то некритично.
Ну а раз уж довелось, то почему бы и да.
И это сказал персонаж, который позволяет себе оценивать ту же Java ни разу на ней не попрограммировав? Мощно, внушаить.
Может раскажите, чему такому можно было научиться на МФ, чему было нельзя было научиться на персоналках? У вас там, в мире IBM, какие-то другие алгоритмы, структуры данных и парадигмы программирования? Или для вас программирование -- это перетаскивание контролов на формочках в визуальном редакторе или автоматизация LotusNotes?
Я начал программировать под Windows в 1993-ем, а под OS/2 в 1995-ом. Имею представление. И то, что OS/2 ничего не светит, было понятно еще в 1994-ом, хотя OS/2 Warp была хороша, но не то, чтобы принципиально лучше WinNT 3.51. Когда же вышла WinNT 4.0 полуось уже можно было закапывать, она могла остаться (и оставалась, что характерно) только в совсем специфических нишах. Даже удивительно, что так долго продержалась.
Посему то, что вы тут изглагаете выглядит как "врет как очевидец".
Ну вы-то не промолчали и выдали статью, в которой выплеснули изрядное количество известной субстанции. А раз ваша статья (за исключением цитат из внешних источников) этой самой субстанцией и является, то почему бы и не озвучить свою оценку?
Кроме того, что вы наговорили откровенной ерунды про перспективы Windows и OS/2 в начале-середине 1990-х, так вы еще и умудрились назвать варварами поколение программистов. На фоне того поколение вы выглядите динозавром, которому повезло прожить свою жизнь в нише мейнфреймов.
Была. У пары моих знакомых были дома БК0010. Это было где-то в 1990-1991 годах.
Не-а. Может вам показалось, что вы добавили ложку мёда в бочку дерьма. Но как бы то ни было, вся ваша статья как была бочкой дерьма, так и осталась.
У нас в провинциальном универе были большая ЕС ЭВМ (1020 или еще какая не помню), какая-то средняя СМ-ка (но мы под нее не успели попрограммировать, только какими-то учебными программами за ней пользовались), Robotron 1715, ЕС 1840/1841, IBM XT и AT. Это 1990-1995-й годы. С 1994-го я уже работал в небогатой компании на 386-х и 486-х.
Да-да-да, статья дает настолько хороший ответ, что чередной читатель вынужден написать:
Ну и вишенкой на торте:
У меня лично не столько конкретный вопрос, сколько удивление на тему того, как можно подобный *овнокод выдавать за решение.
Я про клуб не понимающих какое отношение работы автора статьи имеют к параллельности :)
Вы здесь не первый такой.
Добро пожаловать в клуб!
Это моя реальность начиная с 1990-х годов, еще даже до принятия первого стандарта -- у каждого компилятора было свое подмножество (а в бородатых 90-х, порой, и нестандартное надмножество) C++.
Таков путь.
Прямое следствие того, что есть отдельно стандарт и есть несколько независимых вендоров компиляторов.
Если когда-нибудь все компиляторы кроме одного единственного помрут, ситуация и поменяется, может быть. Но пока этого не произошло, будет именно так.
Жить с этим можно. А страдают от такого, в основном, разработчики кросс-платформенных библиотек и кросс-платформенных приложений. Если же проект живет в рамках одной платформы и одного компилятора (а таких, как оказалось, немало), то и проблем особых нет.
Назвать C++20 небольшим стандартом как-то сложновато.
Да и грядущий C++26 тоже маленьким не назовешь...
Ой как удобно: сперва наговорили кучу не относящихся к техническим вопросам слов о том, что я вам кого-то напоминаю, затем откровенно перешли на личности желая узнать кто перед вами, а когда вам ответили тем же в духе "а судьи кто?" вы стали играть обиженку.
На ваш технический вопрос, кстати говоря, бы дан ответ.
Ну вот любой желающий может заглянуть в ваш VCPa и сделать для себя вывод стоит связываться с таким кодом или нет. Я для себя сделал.
ЗЫ. Можно развлечь себя рассматриванием, например, класса LConvStr и его реализации.
"Только та революция чего-нибудь стоит, которая умеет защищаться." Вы бы должны были бы помнить.
Нет, в комментариях к вашим статьям начинается "коллеги, а не втирают ли нам какую-то дичь?"
Тут есть встречные вопросы: а хватит ли у вас мозгов и опыта разобраться в том, что вам пишут оппоненты? А то ведь по качеству текстов ваших статей и ваших комментариев есть серьезные вопросы по первому пункту, а исходные тексты вашего VCPa заставляют задуматься о том, а умеете ли вы программировать вообще. Студенты 3-го курса должны бы код лучше выдавать.
Как минимум, утилизирующую одновременно больше одного вычислительного ядра.
Более того, использующую доступные вычислительные ядра для сокращения общего времени выполнения задачи за счет распараллеливания выполняемых операций.
Блин, я вам ссылки на Wikipedia давал, где описывается, что есть parallel computing.
Или тут опять вопрос к вашему умственному развитию и опыту, раз вы написанное там не в состоянии понять?
Тогда вам нужно перестать употреблять термин "параллельное программирование" (aka parallel computing).
Ну так и употребляйте термин "конкурентное программирование" или "конкурентность" (aka concurrent computing).
А то вы приходите на уже накрытую поляну параллельного программирования со своей специфической темой конкурентности в однопоточном режиме и потом обижаетесь, почему вам напихивают полную панамку.
Причем вы не правы в очень важном моменте: из ваших статей не становится понятно, что вы путаете "паралелльность" с "конкурентностью". Это, в лучшем случае, выясняется в комментариях, когда вас начинают
размазыватьприпирать к стенке конкретными вопросами.Удивительно, что всего три минуса и так мало "хейта". Поскольку вы задекларировали решение "кошмара параллельности", а по факту предложили подход из категории "устранение перхоти путем отсечения головы": ваша библиотека тупо не может запускать код в параллель и принципиально отказывается использовать больше одного вычислительного ядра современных CPU. Т.е. ваше "лекарство" от "кошмаров параллельности" -- это полный отказ от той самой параллельности.
Что в современном мире, где рост вычислительной мощности уже давно идет за счет увеличения количества ядер, тогда как прозводительность на одно ядро растет все меньше и меньше.
Жалко, что здесь в качестве реакции на комментарий можно поставить либо +, либо -. Смайлик в данном случае очень бы не помешал.
Оказывался в подобной ситуации. Мое решение было в том, что у приложения была отдельная фоновая нить, которая занималась подобной "чисткой". Когда нужно было дождаться завершения рабочего треда с последующим удалением связанного с тредом объекта, то этой фоновой нити отправлялось специальное сообщение с нужной информацией. Фоновая нить получала сообщение, делала join и дожидалась завершения рабочей нити, после чего удаляла нужный объект.