@Vituskosoy Метки одинаковые есть, я даже сказал бы они идентичны. Но Первый поток не мог перепрыгнуть аж в конец скрипта второго по какой-либо из них, так как там ещё нужно проработать блоков так 10-15 до них. Но теория интересная. попробую, поменять имена меток всех.
@tekerosi Сложно что то конкертное вам порекомендовать. @sergerdn прав по поводу того что метки и глоб переменные часто могут руинить логику, но это совсем не значит что их нельзя использовать. дело в том как вы их используете. Тут скорее всего так и есть, и где-то в многопотоке метку что то тригрерит и логика не такая как нужна. Вы говорили что в одном потоке все работает отлично. Так если вам всего два потока нужно то запустите по одному потоку в разных инстансах, и работайте так. Порой это быстрее чем копаться не пойми где.
@tekerosi said in Ошибка при работе в многопотоке:
и как я заметил когда второй поток переходит на вторую часть скрипта, первый поток перепрыгивает на скрипт второго потока
Это похоже на то что идет наложение меток и когда один из потоков тригернул общую метку она сработала во всех потоках.
Возможным решением будет попробовать разделить метки для каждого потока так как вы разделили переменые через условие.
Также если у вас есть метки в которых хопы не в рамках одной функции это тоже может пагубно влиять на логику в запуске или вовсе ее руинить.
Также насколько я помню, если запускать один и тот же XLM в нескольких окнах метки и глоб. переменные тоже будут тригерится друг на друга между окнами.
Также после каждой метки можно поставить какое-то сообщение указывающее явно для вас что это за место. так можно проверить Дело это в метках или нет.
@lesliwp said in Ошибка при работе в многопотоке:
@sergerdn
Привет, метки и глобальные переменные почему лучше не использовать?
@hvrsh said in Ошибка при работе в многопотоке:
@sergerdn прав по поводу того что метки и глоб переменные часто могут руинить логику, но это совсем не значит что их нельзя использовать. дело в том как вы их используете.
Метки и глобальные переменные надо уметь готовить. А кто умеет готовить их, тот понимает, что есть пути менее плодовитые к багам. И не использует их.
Парадокс.
@hvrsh said in Ошибка при работе в многопотоке:
@sergerdn Есть вариант буфер в многопотоке лочить без глоб. переменых?
Можно использовать файловый lock, как имитацию mutex. Вероятно, в это случае без NodeJS не обойтись.
BAS как-то по особенному работает с потокам, может быть можно взять эксклюзивный lock по простому. Но я не знаю как.
@sergerdn посмотрел бы с удовольствием на реализацию, т.к мне как пользователю баса с каким не каким но опытом малопонятно это предложение, и чем это вариант объективно лучше глоб переменной. В основном люди идут по пути упрощенния что на первый взгляд не сказать об вашем варианте.
@hvrsh said in Ошибка при работе в многопотоке:
@sergerdn посмотрел бы с удовольствием на реализацию
Еле нашел релеватную инфу блокировкам - http://community.bablosoft.com/post/159366.
Вкратце, то в BAS код может быть не асинхронным. А вызывая синхронный код в одном из потоков, все остальные потоки ждут и ничего не делают.
И получаем глобальную блокировку всех потоков выполнения как некий побочный эффект.
В NodeJS можно использовать https://www.npmjs.com/package/async-lock.
@hvrsh said in Ошибка при работе в многопотоке:
и чем это вариант объективно лучше глоб переменной.
Я исхожу из того, что глобальные переменные это плохо, так как захламлять пространство имен не может быть хорошим стилем программирования. Для меня это аксиома.
И как будут вести себя модули, если внутри модуль будет работать с глобальными переменными, это я не знаю. А если не знаю, то и не использую.
Вероятно, есть варианты, когда не остается никаких путей, кроме глобальных переменных, например:
