Народ, хотелось бы научить обработку работать на 2 потока - когда-нибудь будет реализована такая возможность??? Как считаете???

Она уже есть. Рег задания.

Всем кому нужна такая возможность, ее уже давно используют.

Когда у тебя мозги включатся

(0) Дык, а сейчас? Запустить несколько фоновых задания.

(0) переходи на Java

имелось ввиду:

при работе 1 пользователя - 1 обработки - процессор грузиться не более, чем на 25% (4 ядра).

(6) Так 1С же скоро выпускает собственную ОС. Вот тогда и будет.

(7) А собственный телефон и планшет будут?

короче, все пофигу, я так понимаю...

(9) Конечно пофигу. Хочешь загрузить 4 ядра запускай 4 сеанса и грузи на здоровье :)

как запустить несколько фоновых заданий паралельно?

(0) Какую конкретно задачу решаешь?

(12) загрузка документов

(11) вот, интересная вещь

(13) зачем тебе многопоточность?

http://catalog.mista.ru/public/387232/

Про фоновые задания уже было?

(0) У тебя через веб сервер подключение и поэтому на 25 только загружается проц?

(13) При многопоточной загрузке будешь постоянно упираться в блокировку, а это надо?

(19) Можно грузить в различных потоках различные сегменты данных, которые почти не пересекаются или слабо пересекаются.

(0) Никогда. Ибо нефиг!

При загрузке документов можно распараллеливать работу под разными пользователями. Выгружаешь кусками и загружаешь кусками. Про блокировку уже тут написали.

Что даст загрузка документов под несколькими пользователями? Вы что пологаете основной тормоз это перадача данных 1с sql? тормоз sql при записи. так что хоть один сеанс хоть 10 разницы никакой.

(8) В девятой версии

Она уже есть
Почему 1С не сделает многопоточного клиента, если он уже есть?

(0) Нет, не будет. Квалификация большинства программистов 1С слишком низкая для нормальной разработки многопоточных приложений.

(15) Как зачем? Чтобы на дедлок нарваться.

(20) А если они в плане обмена все?

(25) ну и бред.

сервер многопоточен, клиенту это не надо, имхо

смешались в кучу кони, люди... а ведь всего лишь про многопоточность спросил...
А что это вообще "многопоточность" - топикстартер об этом знает?

(30) не совсем так, а точнее: не весь код, исполняемый в  контексте Сервер многопоточен. Даже хуже того, весь 1С:код вообще нигде не многопоточен.

(29) где бред?

Клиент вполне себе многопоточен.

(32) эммммммм а как-же работает кластер серверов 1с ???

ну и если быть честными то у сервера рхостов может быть много и все они работают параллельно (многопоточно). Правда не рамках разных сесий :)

(35) то, что вы видите параллельно запущенные процессы в списке _процессов_ - это в самом деле _процессы_
Многопоточность внутри процесса и она не видна в списке.
Многопоточность можно было бы увидеть, если бы в один момент времени процесс выполнялся на нескольких ядрах в несколько потоков. Гораздо проще, во всех отношениях, не пытаться запараллелить, а стартовать новые сеансы в новые процессы, которые будут отрабатывать и самоликвидироваться по завершению своего исполнения.

Это я все на опыте своего давнишнего программирования на С++ испытывал, когда еще 1С-кой только шабашил, а на основной работе только С++ занимался.

(35) работающие параллельно процессы - это еще не означает, что все процессы исполняются многопоточно. Каждый исполняемый процесс загружает только одно ядро, которое ему выдал планировщик.

Да и очень простой аргумент - если у нас открыта неким процессом транзакция на обработку данных (операции ввода-вывода) для какого-то количества таблиц, то обработка исполняемого кода в этой транзакции в любом случае должна завершиться один раз раз в точке фиксации транзакции. Как можно многопоточить одну транзакцию? А несколько отдельных разных транзакций можно выполнить просто в разных процессах (с разными сеансами, например). Что и делается при выполнении фоновых заданий, например. И мы можем увидеть на списке сеансов в "Консоль управления (ММС)", что каждый раз фоновые задания действительно запускаются в разных сеансах - там даже порядковые номера этих сеансов выводятся.

(37) Вот сейчас глянул - у клиента 1С 7 потоков запущено ;)

37+ * Каждый исполняемый процесс загружает только одно ядро - это в случае 1С

(37) Многопоточить одну транзакцию не надо :-) Нужно многопоточить разные транзакции.

(38) ну да, потоки как бы есть - для морды клиента

(40) не многопоточить, а параллелить - так будет ближе в англоязычной терминологии

(38) самое простое в использовании потоков - зацеплять новые потоки за  каждым новым фреймом. Эти фичи уже давно сидят в библиотеках.

(36) Хоть кто то что то понимает

(44) В рамках 1С впрочем большинство подгоняет это под то что разные процессы кластера грузятся. Что впрочем почти тоже самое. Я тока понять не могу для каких задачь эта хрень. Если основная нагрузка на запись данных, где рулит sql и он сам по себе многопоточен.

(45) *хрень=(0)

(40) Вообще, в рамках задачи по загрузке объектов (в случае если он упирается в ЦП) надо параллелить только подготовку объекта в памяти, а затем передавать его отдельному потоку, который и пишет в транзакцию. Вот на этом этапе у 1Сников и возникает вынос мозга, а потому нет смысла давать им гранату.

(44) Частицы "то", "либо", "нибудь", "таки", "да" - пишутся через дефис. Например: Кто-то, что-то, когда-нибудь и т.д.
(45) И перед что ставится запятая внутри предложения.

(45) Заносить данные в регистр по разным измерениям. Или в разные регистры.
Без многопоточности.
1. Делаем запись в первый регистр , или по одному измерению.
2. Ждем.
3. Записываем новый блок данных.

С многопоточностью.
1. Первый блок данных. 2. Второй блок данных. ....

Я так понимаю.

(43) Кстати, вспоминается мне сейчас: вот эта самая многопоточность, даже если она в программистком смысле уже задействована внутри процесса, то самое, что показывает список процессов, что потоки запущены - этим потокам на низком уровне планировщиком должна быть назначены собственные адресные пространства в оперативе, какие-то там дескрипторы и т.д. и т.п., а уже затем, при обеспечении полной(!) _изоляции_ одного потока от своего соседнего внутри(!!) общего породившего их процесса, будет возможна передача исполнения потока на параллельно доступное(!!!) ядро.
Так вот, проблема планировщиков заданий у современных операционных систем в том, что большинству существующих приложений они не могут выдавать доступ к нескольким ядрам одновременно одному процессу. Из-за плохой изоляции данных разных потоков между собой.
Но все-таки известны примеры приложений, которым удается реализовать на практике многопоточность с параллельной загрузкой нескольких ядер. Самое популярное такое приложение - это MS SQL

(48) Включи ассоциативное мышление возможно начнешь понимать написаное без черточек

(49) Два процесса пишут в одну и туже таблицу, в итоге передавая управление sql. У нас что тормоза на уровне передачи  данных в sql?

(0)(13) Ну запусти еще один сеанс да загружай себе. Все равно время загрузки будет одинаковое при одном потоке или при десяти. В один поток даже быстрее будет, не будет байды с блокировками. Диск то у тебя один и кабель сетевой тоже один. Короче иди работай.

(52) Ну смотри . Допустим, пишем 2а набора в разные регистры.

Код :

Набор1.Записать()
Ждем записи....
Набор2.Записать()

А так это одновременно будет происходить.

(50) 64х сервер 1с вполне себе умеет из одного потока загружать все ядра сервера.... именно по этому 1с рекомендует только 1 рхост....

да и вообще множество рхостов в 1с - появилось не из-ла неумения грузить процы а из-за ограничения памяти

(55) Это ты сам придумал???

Ты путаешь процесс и поток

(55) При чем тут 64?

(50) Ой, да ладно. На раз-два делается.

(58) это чтобы ересь умнее выглядела

(54) Это понятно. Непонятно приминительно к какой задаче это. к тому же как уже говорили в другой ветке просто запускаешь разные сеансы по разным видам документов (запись без проведения). Только вот писать надо сразу в sql, а так это всё игрушки.

(61) В загрузке документов смысла,наверное, нет.

(59) могу только озвучить дополнительно, что это все имхо - причем, в лурковской расшифровке этой аббревиатуры

з.ы. Не могу отнять у людей права на высказывание своего имхо :)

Ответ в первом посте. Все остальное бред какой то. Если по блокировкам не пересекаются данные, дели на 2-3 части и запускай в фоновых заданиях. На больших объемах будет ускорение процентов на 40-60. Какие нафиг скуэли и рпхосты.

(64) а ты пробовал? откуда 40-60 процентов взял?

(65) Пробовал. Наибольший прирост дают 2-3 задания. Писал в справочник много элементов параллельно, документы грузил, не помню уже точно, выгружал что то. Это все тестовые задачи были на которых изучал я как раз фоновую параллельность эту.

Например задача: нужно отсортировать по порядку огромнный массив, используя многопоточность. Как это сделать на клиенте.

(67)
написать вк. 1с не предназначена для таких задач.

(67) делишь данные например на две части, запускаешь асинхронно фоновые задания каждый со своим куском данных, в цикле ждешь отработки заданий, сливаешь по алгоритму результат.

(69) Но фоновое задание это процесс, а не поток. И к тому же выполняется на стороне сервера, а я спрашивал на клиенте.

(67) в 1с не бывает огромных массивов. вместо огромных массивов в 1с есть "память закончилась"

(70) тебе надо быстро обработать массив данных или повы...ваться? кто на клиенте это делает, да еще и в 1с?

не предметный разговор. многопоточная сортировка на клиенте в 1С... че за бред.

(66) Зависит от многих параметров. И в первую очередь от скорости дисков.
На ССД например очень хорошо параллелится запись, на обычных практически нет

(72) Я, например, это делаю, и не считаю это чем-то плохим.

(74) при одинаковых условиях. на 5 потоков поделишь, не сильно быстрее будет чем в 2-3. не в пять раз быстрее. на 10 поделишь еще и медленней будет. издержки видимо влиять начинают.

(73) Сортировка массивов, используя многопоточность, это стандартная задачка в учебниках по программированию. Я и привел этот пример. Конечно может на практике он и ни кому не нужен.

(75) Но на практике это нахер не нужно.

(69) И залюбишься ждать результата.

Все разговоры о многопоточном клиенте закончаться ровно тогда, когда 1С реализует метод ДокументОбъект.НачатьЗапись()

(77) в задачках по программированию многопоточность есть. Но не факт, что эти задачки на низком уровне используют несколько ядер или процессоров.

(81) Согласен, что не факт. Но все же будет быстрее, если запустить на 1 потоке.

создал два справочника. создал два фоновых задания для добавления 10000 записей. запустил оба задания. сначала выполняется первое, потом второе. ничо не понял. похоже эти задания добавляются в очереди и выполняются последовательно в порядке очереди.

+(83) так что про 40-60% прироста производительности в (64) высосано из пальца похоже.

(80) хахахахаха

(83) они асинхронно должны запускаться.

(83) Резиновую кияночку подарить?

2(86) ну они асинхронно запустились. сначала одно, потом асинхронно второе

(88) ааааааааааааахахахаах )))) да что за юмор ветка .. )))

(86) да они тупо в очередь добавляются и выполняются по очереди параллельно с основным потоком. так что больше двух потоков не получается.

(89) укурился чтоли

(82) Почему два потока в процессе на одном ядре будут быстрее, чем просто один процесс на таком же одном ядре?
Тут даже логика подсказывает, что на два потока будет еще и больше затрат ресурсов на постоянное переключение ядра с одного потока на другой.

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

В обслуживании многооконного интерфейса выгода будет:
- в передаче управления на несколько окон параллельно
- в отображении/прорисовке нескольких окон параллельно.

загугли уже пример.

(92) Не так - пока один висит, второй будет работать. Отсюда при зацикливание ось не вешается, а продолжает работать.

почитал ИТС. Понятно теперь. Короче, в клиент-серверном варианте будет работать несколько фоновых заданий параллельно, а в файловой базе будет выполнятся последовательно.

(80) Поясни, пожалуйста.

(96) Пользователь нажал кнопку Провести, форма документа стала недоступной, но управление передалось пользователю.

(96) Но основная проблема в том, что работа с интерфейсом 1С, с GUI синхронна. Исторически скорее всего так.
Как только начинает выполняться код 1С, интерфейс пользователя становится недоступным.
При этом - мы прекрасно можем выполнять код 1С в отдельном (своем, неучтенном 1С) потоке (например во внешней компоненте) до тех пор, пока не трогаем интерфейс. Как только трогаем интерфейс - 1С как минимум ловит глюки интерфейса, как максимум - валится.

(98) фоновое выполнение отчётов в бсп ты не рассматривал?

2(99) Ну вот а почему так не сделать с документами - непонятно.

(99) Рассматривал. Но речь идет Документы, Денис!

Карл, Фридрих-Иероним!

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

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

(98) Синхронный GUI это фиг с ним, можно перетерпеть. А вот многопоточное выполнение кода нужно.

(103) А как же отложенное проведение. И есть по сути асинхронное

(103) "алгоритмы проведения распараллелить"
да это же невозможно. там нечего распараллеливать. диск ты всё равно не распараллелишь.

2(105) господи, да легко - сколько шпинделей - столько и записей. А если буферпулы настроить на максимум, так вообще

(106) ты регистры будешь по шпинделям распределять? ну ну.

(105) Да ну? А расчет зарплаты? А расчет себестоимости? А выравнивание партий? Что у нас там еще долго проводится?..

До возможностей диска там как до луны.

(107) бывают ведь ссд

(108) в упп партии отлично параллелятся: отдельно БУ, отдельно НУ

2(107) Сервер БД их будет распределять

(104) Есть. Но это другое. А при интерактивном надо сейчас.

нет, собственно даже не сервер, а контроллер диска, то есть файловая система. А Сервер БД будет стараться их держать в буферпулах, и только со временем экстренализировать на диски

(113) не все так радужно как ты думаешь

2(114) ты не можешь знать как я думаю и как я делаю.

(105) Какой диск?? БД в памяти вся балтается

(107) Я распределял. Лучше было

(116) Это у вас детских размеров БД.

2(118) для недетских есть тэйблспейсы, который... чорд, опять болтаются в памяти целиком

(118) Сколько весит твоя?

Как минимум нужна многопоточность в конфигураторе при обновлении. Там ничего сложного все распаралелить

Используем фоновые для проведения кучи документов. Профит 8 часов против последовательного 50 + часов

+(121) Лично мне бы это экономило десяток-другой рабочих часов в месяц. Думаю по всей отрасли это бы исчислялось сотнями тысяч человеко-часов в месяц экономии, причем не абы кого, а квалифицированных специалистов.

вот с чего люди взяли что многопоточность прям в разы увеличит производительность.  
когда у нас будут 1000 ядерные процессоры и 1000 канальная память, тогда можно будет чего то ждать.
просто ради эксперемента, запустите два потока которые будет крутить цикл от 1 до 1000000000 и засеките время выполнения одного из этих потоков. потом запустите один поток на 2000000000. время выполнения двух потоков на 1000000000 и одного на 2000000000 будет одинаково.
я уж молчу про блокировки ресурсов, память, диски и т.д.

не забываем про закон Амдала

(124) ерунда

Я когда видео декодировал с DVD в mp4, двухядерный проц гораздо быстрее это делал. чудеса?

(124) Хотят просто писать в разные таблицы. И тут будет в разы.

(126) одноядерный P4 против двухъядерного i5 ?

(127) ну можно попробовать. для начала, запустить два раза одну базу и засечь время на добавление в два справочника 100000 записей например. потом запустить одну и сделать тоже самое два раза подряд. засечь время.

(128) Athlon64 и Athlon64 X2 .. одни из первых

Как я уже написал в статье на Инфостарте, мы уже юзаем универсальные многопоточные обработки: объединение дублей, обмен данными, свертка регистров, произвольная обработка объектов. Действительно к квалификации разработчика при переходе к многопоточности повышаются требования. Рано или поздно в БСП появится подсистема "Многопоточные обработки данных". У многих в том или ином виде она уже есть. Без подсистемы многопоточность при работе с данными кодировать с нуля весьма неэффективно.

(130) ну само собой, если программа может использовать несколько ядер процессора, то прирост будет. но применительно к 1с ждать увеличения производительности в разы, даже если 1с будет использовать несколько ядер - глупо.

Многопоточность нужна.
Например, массовая рассылка прайсов, когда часто приходится рассчитывать и отправлять по 1000 штук.
Пробовал через фоновые задания - тяжело идет.
Фоновые задания в текущем виде - это тормоза. Тяжело запускаются, а результат возвращают через задний проход.
Запуск каждого задания - это несколько секунд, и если задача мелкая (прайс формируется несколько секунд) - дольше ждать запуска этого задания.

(126) в библиотеках для кодирования в мп4 _специально_ установлены многопоточно выполняемые _расчеты_, обращаю особое внимание на выполнение _Расчетов_, а операций ввода-вывода на диск. Более того, именно специфика обработки данных с кадрами сжатия в мп4 - это когда берутся достаточно большие куски видео без сжатия (последовательность кадров) и в них от опорных кадров сохраняют последовательности сжатых изменений.
Естественно, что разные опорные кадры с последовательными блоками несжатых кадров очень эффектно можно сливать в разные потоки на разные (и действительно разные) ядра. И это все обязательно происходит в _выделенной_ оперативной памяти, иначе не получится запросить у планировщика и получить от него еще одно новое ядро на еще один новый поток

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

я в ЗИК 7.7 рассчитывал налоги из нескольких копий программы по разным подразделениям одновременно...прирост скорости действительно в разы в итоге получался

при правильном подходе многопоточность может сильно помочь

(135) а я наоборот всегда делаю последовательно, потому что кроме нагрева системы ничего не увеличивается.

(135) изоляция рабочих наборов данных это действительно мощная штука. Иначе транзакция тебя просто поставит в очередь и все.

(124) Запусти на i7 c 32 Гб оперативки и SSD обновлять несколько баз последовательно, а затем параллельно и подсчитай многократный выигришь в скорости.

(137) угу...так считать 500 человек 60 минут, а параллельно за 15...ничё не увеличивается совсем...особенно когда на улице 8 вечера..а дома жена ждёт

(137) но виртуально сложно оценить насколько изолированы получались данные друг от друга.

(140) как у тебя эти 500 разделены были? в разных документах расчетов, т.е. в разных табличных частях и т.п.?

(140) а я никогда на работе не задерживаюсь. закон такой.

(141) ЗиК 7.7, там было понятие журнала расчётов, и рассчитывалось всё отдельной обработкой.
разделены по разным подразделениям
(142) а это у меня "удалёнка", и во времена хренового интернета приходилось туда ездить физически

(103)
>> Синхронный GUI это фиг с ним, можно перетерпеть.
>> А вот многопоточное выполнение кода нужно.
Все наоборот.
Как раз GUI должен быть "живым" и быстрым.
Чтобы нажал "записать и закрыть" - сервер сказал "Ок, записываю...", а ты тем временем можешь начать ввод данных в следующий документ.

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

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

(143) угу. вспомнил. главное, чтоб список выбранных сотрудников не пересекался. Самое смешное, что я так сам тоже делал. Сколько уже лет прошло... Отбираемые сотры по подразделениям, чтоб не повторялись в разных сеансах и погнали :) А если на разных компах, то и вообще красота. Компы тогда не могли похвастаться "лишними" ядрами.

>Чтобы нажал "записать и закрыть" - сервер сказал "Ок, записываю...", а ты тем временем можешь начать ввод данных в следующий документ.

до сих пор нет 64-битного клиента под винду... какие там "ок, записываю"

(146) кстати, сам не смотрел, а для линукса там какие клиенты? Тоже 32 бита? Хотя, большой разницы только одно это не даст.

(140)получается, чем больше система тратит время процессора, тем больше чудес можно ждать от распараллеливания. если бы 1с была офигенно быстрой и не тратила время процессора на какую-то фигню, то она упиралась бы только в запись на диск.

(147) под пингвина есть 64... но у кого есть пингвин?

это даст хотя бы то что клиент и пофигуратор не будут падать от объемных операций

>если бы 1с была офигенно быстрой

она в 10 раз медленнее дельфей. и можно ли с этим что-то сделать? интерпретатор же

(148) под многопоточность надо писать правильные программы

например если есть много однотипных объектов, не связанных друг с другом, их обработку можно очень эффективно разделить по отдельным процессам - по количеству ядер процессора

просто тупо "сделать многопоточную платформу" тут не получится. надо каждую конкретную задачу рассчитывать под распараллеливание

(150) я думаю, что и интерпретатор можно сделать быстрее нынешнего раз эдак в 5.

(150)
>> интерпретатор же
Это отмазка :).
Интерпретаторы тоже могут быть быстрыми, это по большому счету претензия к компилятору.

Да и дело наверное не в интерпретаторе. Никто же не пишет циклы на миллионы итераций и не вычисляет числа Фибоначчи. Оно просто внутри тормознутое и нам с этим жить. И довольно неплохо в материальном плане. :)

(98) Это не только с 1С. Очередь сообщений привязана к потоку. Обращайся к GUI из её потока.

А вообще в нормальных языках большинство функций асинхронны

http://www.codeproject.com/Tips/8059...PI-ASP-NET-MVC

Я вообще промолчу про ленивые функции итд.

http://www.codeproject.com/Tips/805923/Asynchronous-programming-in-Web-API-ASP-NET-MVC

(133) Это как раз пример неправильного использования многопоточности.

> если задача мелкая (прайс формируется несколько секунд) - дольше ждать запуска этого задания.

Так запускать надо один раз. Раскидать всю пачку по заданиям, каждому по 200 клиентов, допустим, и пускай формируют и сразу рассылают.

(158) Та же многопоточность, только вручную. Так и делаем.

Только - виндовым планировщиком, так надежнее.

(144) >Как раз GUI должен быть "живым" и быстрым.
Против этого не возразишь.

>Чтобы нажал "записать и закрыть" - сервер сказал "Ок, записываю...", а ты тем временем можешь начать ввод данных в следующий документ.

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

(156) Асинхронность у нас уже есть.

(161) Согласен, что бухи так делать не будут. Ну ведь 1с утверждает, что она не только в бухе хороша, но и почти в любых учетный системах не связанных с бухгатерией.

(162) Как говорят в 1С: Не путайте асинхронность и многопточность

Но в 1С как всегда: бессмысленная однопоточная асинхронность

(163) Если документ после ввода не требует контроля со стороны системы, то его и проводить не надо, просто сохранить. А проводить можно и фоновым заданием.

А сохраняет 1С быстро, тут многопоточность не нужна.

Бойтесь своих желаний... А то будут при сдаче на сертификате что-нить такое спрашивать: https://www.youtube.com/watch?v=iB2N8aqwtxc

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

(168) А как же "начать задавать вопрос"?

(161)
>> набил половину следующего, а тут бац - предыдущий ругается: где-то что-то не так заполнил

Согласен. Тут я немного недописал.
Конечно-же проверки заполнения должны быть быстрыми синхронными.
Касаемо целостности остатков - возможно резервирование товаров должно быть максимально легким и выполняться не в момент проведения а в момент проверки заполнения или даже еще раньше - в момент набивания товара.

>> ... бухи ... сначала убеждаются, что док провелся корректно и так, как им нужно.

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

(169) Не понял?

(171) Асинхронные методы, один из которых ПоказатьВопрос()

НачатьПомещениеФайла и тд и тп

Это не асинхронные методы, а продолжатели которые выполняются в одном потоке. Не надо путать с модальностью.
Примером асинхронности это AJAX.
Или элементарный пример чтения данных из COM порта

sp = new SerialPort("COM" + НомерПорта.ToString());

            sp.BaudRate = 9600;
            sp.Parity = Parity.None;
            sp.StopBits = StopBits.One;
            sp.DataBits = 8;
            sp.Handshake = Handshake.None;

            sp.DataReceived += (sender, e) => {
                SerialPort sp1 = (SerialPort)sender;
                string indata = sp1.ReadExisting();
              
                    Sc.Send(d => EventTo1C.ExternalEvent("ДанныеОтСканера", sp1.PortName, indata), null);
                    

            };

            sp.Open();

(174) См (164) до просветления

(175) И?

http://habrahabr.ru/post/51762/

https://msdn.microsoft.com/ru-ru/library/hh191443.aspx

И где противоречие?

https://msdn.microsoft.com/en-us/data/jj819165.aspx
(179) Противоречие с чем?

(172) Это не что иное как подписка на событие ПриЗакрытии.

(167) Хрень какая-то.

181 в 7.7 Тоже для возврата результата в вызвавшую форму применяли Открытие Формы родителя, а внутри использовали метод ПриПовторномОткрытии. Но почему то тогда никто не называл этот прием асинхронным программированием

(182) Разработчик JVM рассказывает о том, как реализована поддержка многопоточности в JVM)
И почему реализована именно так.

(174) >Это не асинхронные методы, а продолжатели которые выполняются в одном потоке.
WAT?

(185) "Продолжатели", которые запускают доп. потоки обработки и передают им точки вызова при завершении. Все по классике.

(186) Господи, как тока callback'и не обзывают.
И да, по классике callback'и никак не связаны с multithreading'ом)

У нас многопоточность используется через фоновые задания. Чтобы заполнять отчетность параллельно. Прирост заполнения в несколько раз по сравнению с последовательным заполнением (до 10 потоков). Итоговый выигрыш в несколько часов. Единственное, иногда фоновые задания отваливаются и приходится это отслеживать в отдельном фоновом задании.

(186) С точки зрения асинхронного программирования синхронный метод блокирует рабочий поток. За счет того, что метод выполняется в рабочем потоке либо ожидает завершения асинхронного метода (работа с сокетами) с помощью объектов синхронизации до получения события (монитор, мьютекс).
С этой точки зрения вызов модального окна не является синхронным, так как его очередь работает в этом же потоке, можно вызвать методы в этом же потоке. Спецификой модального окна является то, что оно перехватывает все события другим окнам приложения, и после выполнение возврат кода происходит на следующий оператор за вызовом модального окна. Никакого отношения к асинхронному прогпаммированию модальное окно не имеет.

(187) Под продолжателями я имел ввиду делегаты вызываемые при событии ПриЗакрытии. Никакого отношения к асинхронному программированию они не имеют.

(189) (190) Кончай теоретизировть. Речь шла о методе ПоказатьВопрос() и ему подобных. Обработчик, передаваемый туда, выполняется асинхронно. Вот я и возмутился.

(92) С чего ты взял, что у процесса только 1 ядро доступно? По умолчанию доступны все ядра, если только affinity mask не задать.

(192) Кнечно - гляньте любой архиватор

(105) IOPs'ы у HDD при произвольном доступе растут по мере роста глубины очереди запросов, если чо. Так что 10-20-30% прироста вполне можно получить даже если тормоз - HDD.

(121) Хочешь глюков в Конфигураторе? Они с 1 рабочим потоком-то не могут целостность кеша отладить уже лет 10...

Какой к черту многопоточность. Если уже на носу 8.3.6 и вот вот будет (7). А 1С так и не научилась с сервера возвращать параметр "Я обработка, я не вишу и работаю, вот осталось еще 10% и я вам выдам результат". Я про тонкий клиент.

Пользователь сидит, и непонятно, завершится мего отчет успехом, либо вылетит, либо пользователь соберется домой :)

(194) Да сделайте уже нулевой рейд или 10 ый

(193) Глянул 7-Zip. На 6 ядрах скорость в 4-5 раз выше.

(196) Зачем этот колхоз? С приходом SSD для повышения быстродействия он стал абсолютно ненужен.

(192) Он имеет ввиду, что  2 потока одновременно НА ОДНОМ ядре  не могут работать.

(198) Слава HyperThreading - могут ;) И я бы не стал на это рассчитывать - куча программистов наступила на эти грабли, когда их ПО жестко глючило на многоядерных ЦП.

(191) Это не теория а практика. Ты можешь как угодно называть немодальные диалоги и подписку на события, только к реальному асинхронному программированию оно никакого отношения не имеет.