Если взять за пример другой язык программирования в них существуют различные инструменты для синхронизации потоков, например lock{} (в C#) т.е. обернув какой-то участок кода в lock мы будем уверены, что этот код будет выполнен последовательно. Вот нужно так же в 1С сделать )) т.е. что бы конкретная процедура выполнялась последовательно.

Пример:
запуск в фоне процедура1

процедура1 - ветвится:
процедура1
   вызов процедура2
   вызов процедура3
      вызов процедура5
         вызов процедура7 - и вот только 7-ю нужно выполнять последовательно, что бы ФЗ ожидали выполнение этой процедуры другим ФЗ
      вызов процедура6
   вызов процедура4

в 1с, в рамках одного фонового задания отсутствуют потоки и параллелизм....

чего конкретно тебе надо?

https://its.1c.ru/db/metod8dev#content:5839:hdoc

(1) а кто говорил про одно?

(2) это блокировки БД, причем тут они?

(3) ты хочешь все процедуры из (0) запускать в разных фоновых заданиях?

(5) какие все? запускается только одна процедура1, но она вызывает другие процедуры и функции, которые в свою очередь тоже что-то вызывают и да, процедура1 будет выполняться в параллельно (в нескольких ФЗ)

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

(7) ясно, буду искать пути решения

(6) то есть алгоритм такой

1. вызываем несколько фоновых заданий, в каждом из которых выполняется "процедура1" которая может вызывать строго последовательно другие функции но не запускает другие фоновые задания
2. когда все фоновые задания закончились - вызываем "процедура7" с мараметрами получеными из предыдущих фоновых заданий

я все правильно расписал?

(7) Вы зря так категоричны... я делал и семофоры и паралеьные данные....

давайте для начала поймем чего автору надо

(9) нет
(10) чего мне надо я написал, ты работал с многопоточностью в других языках, знаешь что такое критические секции? Вот их аналог нужно реализовать.

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

(11) есть много вариантов,

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

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

3. можно через внешний COM обьект (но его писать надо)


я так до конца и не понял чего надо автору...

даже правильнее так: в недрах *одного из* фоновых заданий выполнить некий кусок кода, тогда как *остальные* задания должны остановиться и ждать пока выполнится. Затем эти остановленные задания должны продолжить работу с того места где остановились. Не, мне кажется, нормально на 1С это не сделать. Во всяком случае не знаю как.

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

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

(4) При том, что блокировка и ожидание ресурсов, которым являются твои критические секции, в 1с делаются через общие объекты в базе данных.
Можешь, конечно изобретать квадратные трехколесные, зато свои.

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

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

и исходить нужно именно из этого

(0) Тока не говори что в королевстве кривых зеркал задумали многопоточность с честной асинхронностью делать

В 1С нет и не будет всех этих мьютексов. По причине:
1) Кластерности сервера 1С.
2) отсутствия обратного вызова сервер>клиент

Делать критические секции на объектах БД - верх жести.

(20) 1. Пофиг на кластерность сервера 1С, ибо многозадачности будут отдельные для клиента и сервера и для сервера тока в одном потоке "субпотоки"
2. Уже сделали же, точнее нечто вроде

(17) facepalm

(20) причины не ахти, разрабатывают же клиент серверные приложения на языках поддерживающих все прелести многопоточности

(24) Зачем в бухгалтерии многопоточность?

(25) почему обязательно бухгалтерия? Может у меня загрузка чего-то в БД происходит, логично ж делать загрузку параллельно

(26) Для этого вполне достаточно имеющихся средств

(24) Всё опять упирается в сериализацию 1С, вернее в быстродействие.

(0)для этого есть только метод ОжидатьЗавершения у задания, и у МенеджераФоновыхЗаданий.

И да, не будет работать в файловом режиме, и в мобильной платформе. В этих режимах у 1С только одно фоновое задание (чистый идиотизм).

(10) > Вы зря так категоричны... я делал и семофоры и паралеьные данные....

Не особо  типичная задача для учетной системы.

(29) аааааа.... ну не позорьте вы профессию программиста!!!

(32)Это точно мне? :) Чем же я запятнал ее, сударь? Я подсказал вам способ решения вашей задачи.

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

да к учету это не сильно относится, это скорее tools для 1с...

(34) А вот аналог аськи или скайпа в 1С - это одна из нужных на мой взгляд вещей.

(35) уже реализована на уровне платформы :) недавно было в зазеркалье

Сдались вам мутексы и прочее.
Выносите код,который должен исполняться в один поток,в отдельное фоновое задание,чтобы тот,кому он нужен,запускали это задание и ждали его завершения - уж фоновое то несколько раз не запустить.
А через базу не очень хорошо,так как в транзакциях можно что-то не то залочить - точнее, вы блокируете объект и начинаете что-то делать, открываете транзакцию - снимаете блокировку с объекта, но, если вы в нём что-то поменяли, то он будет заблокирован для чтения до окончания транзакции - и ой.

(35) Бери 1C Messenger для отправки сообщений, файлов и обмена данными между пользователям
Можешь написать свой
(36) Там самому то написать несложно. Непонятно, почему они так долго тянули.