написал: мьютексы излишне использовать, так как всего два потока.Ранее уже говорил, что это решается гораздо проще через Event.
Если рассматривать вариант использования только одного экземпляра квика, то да. Но вот у меня, например, на данный момент рабочих целых 4 варианта самостоятельных квиков. Все они используют в работе всегда одну и ту же DLL, которая обеспечивает мне консоль для вывода, ну и разные функции для работы с этой консолью, в том числе и цветной вывод. Для цветного вывода хош-не хош нужна синхронизация, иначе всё идёт в перемешку, хоть и разным цветом, что очень неудобно воспринимать, хотя и можно смириться с этим, но я решил не мириться. Так вот, коли 4 квика, то по сути это уже и 4 разных процесса. И поэтому либо мьютекс нужен, либо быстрая критическая секция. Но секция одна на разные процессы не пойдёт. Я выбрал для себя в реализации именно секции, но приходится хранить массив из секций (для каждого потока своя секция), которые инициализируются при подключении процесса в DLL. Сейчас всё работает как положено. Ну пришлось чуток добавить кода, но оно того стоит думаю.
Возможно не понял, но полагаю что Вы ошибаетесь. --------------------------- Синхронизировать потоки надо при обращении их общим данным. ------------------------- Четыре различных квика не имеют общих данных. Поэтому непонятно, что Вы пытаетесь синхронизировать. -------------------------- DLL - это не данные а код.Не надо синхронизировать потоки при обращении к коду. ----------------------- Не надо синхронизировать потоки при обращении к константам. --------------------- Смысл синхронизации в том, что в момент чтения данных одним потоком, второй их непредсказуемо изменит.
Пользователь
Сообщений: Регистрация: 09.09.2022
11.02.2025 18:31:25
Цитата
nikolz написал: Возможно не понял, но полагаю что Вы ошибаетесь.---------------------------Синхронизировать потоки надо при обращении их общим данным. -------------------------Четыре различных квика не имеют общих данных. Поэтому непонятно, что Вы пытаетесь синхронизировать.--------------------------DLL - это не данные а код.Не надо синхронизировать потоки при обращении к коду.-----------------------Не надо синхронизировать потоки при обращении к константам.--------------------- Смысл синхронизации в том, что в момент чтения данных одним потоком, второй их непредсказуемо изменит.
Да не поняли. Теорию знаю. По DLL тоже, и что и как там и в каком контексте работает, и переменные общие и т.п. Мне синхронизировать нужно работу вывода в консоль. Функции принтов есть в DLL и есть варианты, чтобы они разным цветом печатала в консоли есть функции и для скрипта - для захвата секции и много там ещё чего разного. Даже например внутри одного квика, допустим один поток колбэк выводит в консоль цветной текст - своим цветом последовательно по ходу работы функции принт за принтом. Далее этот поток прерывется и запускается другой поток, который тоже последовательно выводит в консоль своим цветом принт за принтом по ходу работы его функции. Что будет? Будет каша разноцветных принтов в перемешку, да ещё и цвета возможно сбиваться будут. Общие данные - захват консоли на время работы функций потока. Консоль и есть общий ресурс. Функции колбэка быстрые и захватывают консоль в начале функции и освобождают в конце, весь их вывод в консоль одним цветом получается, для каждого колбэка свой цвет, другой поток ждёт и не может ничего вывести пока колбэк не отработает полностью. Т.е. даже когда прерывается поток колбэка и запускается основной - это не страшно, основной кашу не сделает, ибо ждёт, потом возврат в колбэк и он продолжает свой цветной вывод своим тем же цветом. Отработал отпустил. Потом уже основной поток может продолжить и печатать своим цветом. У основного потока каждый принт - захват и освобождение консоли для своего цвета принта через захват секции(не в начале и в конце функции(как у колбэка) в которой принты основного потока - так можно бы было, но кое где логика не позволяет ибо ждёт результата колбэка и можно зависнуть, когда один захватит секцию и ждёт данных от колбэка, а колбэк не может захватить секцию, либо не логика, а просто нельзя тормозить надолго всю функцию основного потока по захвату консоли, ибо колбэки хрен тогда отработают, поэтому захват только на время работы одного принта основного потока). При таком построении каждый колбэк отписывает в консоль своим цветом даже если его прерывают, ну и основной поток спокойно себе печатает своими цветами и не пересекаются их выводы с выводами колбэка. Без этого такая каша, что даже выводы разных колбэков пересекаются, не что что с принтами основного потока и такое читать просто жопа.
Да с этого начинал. Так делал. У меня есть DDL-ли и они все тоже печатают в консоль. Консоль одна на весь процесс квика. Печатают в консоль все - и основной поток с его функциями, и колбэки и функции, которые лезут в DLL из нутри самой DLL и сама DLL. Как там винда это регулирует хрен её знает. У неё там видимо есть общая очередь для всех тех кто в эту консоль пишет и вот как то нихрена не синхронно в эту очередь всё попадпет. Тоесть ждёшь той последовательности вывода принтов от всех, к какой они делаются шаг за шагом и с учётом ныряния в DLL, а получается не так - идёт перемешка. То что перемешка с колбэком то это понятно может, но и просто выводы из скрипта с выводами функций, что заходят в DLL перемешка получается не в той последовательности как вызывается почему-то.Например в скрипте вывел в консоль, потом только идёт вызов функции из DLL, которя тоже выводит в консоль и должны принты идти так, что сначаля я должен увидеть в консоли вывод из скрипта, т.к. он первый напечатал, а потом уже из функции, т.к. она вызвалась позже и печатать в консоль позже должна, но не всегда именно так выходит! Поэтому было принято делать вывод в консоль только из одного места - только из самой DLL. Для всех! DLL сама изнутри туда пишет. Всё, что из скрипта идёт - через принт, который находится внутри DLL. Когда начал делать так, то всё стало работать синхронно в своей последовательности.
написал: Возможно не понял, но полагаю что Вы ошибаетесь.---------------------------Синхронизировать потоки надо при обращении их общим данным. -------------------------Четыре различных квика не имеют общих данных. Поэтому непонятно, что Вы пытаетесь синхронизировать.--------------------------DLL - это не данные а код.Не надо синхронизировать потоки при обращении к коду.-----------------------Не надо синхронизировать потоки при обращении к константам.--------------------- Смысл синхронизации в том, что в момент чтения данных одним потоком, второй их непредсказуемо изменит.
Да не поняли. Теорию знаю. По DLL тоже, и что и как там и в каком контексте работает, и переменные общие и т.п. Мне синхронизировать нужно работу вывода в консоль. Функции принтов есть в DLL и есть варианты, чтобы они разным цветом печатала в консоли есть функции и для скрипта - для захвата секции и много там ещё чего разного. Даже например внутри одного квика, допустим один поток колбэк выводит в консоль цветной текст - своим цветом последовательно по ходу работы функции принт за принтом. Далее этот поток прерывется и запускается другой поток, который тоже последовательно выводит в консоль своим цветом принт за принтом по ходу работы его функции. Что будет? Будет каша разноцветных принтов в перемешку, да ещё и цвета возможно сбиваться будут. Общие данные - захват консоли на время работы функций потока. Консоль и есть общий ресурс. Функции колбэка быстрые и захватывают консоль в начале функции и освобождают в конце, весь их вывод в консоль одним цветом получается, для каждого колбэка свой цвет, другой поток ждёт и не может ничего вывести пока колбэк не отработает полностью. Т.е. даже когда прерывается поток колбэка и запускается основной - это не страшно, основной кашу не сделает, ибо ждёт, потом возврат в колбэк и он продолжает свой цветной вывод своим тем же цветом. Отработал отпустил. Потом уже основной поток может продолжить и печатать своим цветом. У основного потока каждый принт - захват и освобождение консоли для своего цвета принта через захват секции(не в начале и в конце функции(как у колбэка) в которой принты основного потока - так можно бы было, но кое где логика не позволяет ибо ждёт результата колбэка и можно зависнуть, когда один захватит секцию и ждёт данных от колбэка, а колбэк не может захватить секцию, либо не логика, а просто нельзя тормозить надолго всю функцию основного потока по захвату консоли, ибо колбэки хрен тогда отработают, поэтому захват только на время работы одного принта основного потока). При таком построении каждый колбэк отписывает в консоль своим цветом даже если его прерывают, ну и основной поток спокойно себе печатает своими цветами и не пересекаются их выводы с выводами колбэка. Без этого такая каша, что даже выводы разных колбэков пересекаются, не что что с принтами основного потока и такое читать просто жопа.
Вы плохо изучали теорию. Повторю еще раз. Синхронизируют не код, а общие данные. Функция принт - это код. --------------------------- Зачем Вы выводите в консоль? Выводивыводите в лог файл и будет вам счастье. Лог файл позволяет анализировать ошибки и логику выполнения программы при длительном тестировании софта. Например , тестировал скрипт на QUIK 6 часов. При интенсивном потоке данных или длительном тестировании от консоли мало толку. ------------------------- Чтобы при выводе на консоль ничего не съедалось надо ставить задержку после оператора вывода. Обычно sleep(10) достаточно. -----------------------
Пользователь
Сообщений: Регистрация: 09.09.2022
11.02.2025 20:10:46
Цитата
nikolz написал: Вы плохо изучали теорию.Повторю еще раз. Синхронизируют не код, а общие данные. Функция принт - это код.---------------------------Зачем Вы выводите в консоль? Выводивыводите в лог файл и будет вам счастье. Лог файл позволяет анализировать ошибки и логику выполнения программы при длительном тестировании софта.Например , тестировал скрипт на QUIK 6 часов. При интенсивном потоке данных или длительном тестировании от консоли мало толку. -------------------------Чтобы при выводе на консоль ничего не съедалось надо ставить задержку после оператора вывода. Обычно sleep(10) достаточно.
1) Вот только не надо мне про плохо теорию. Синхронизируется никакой не код, а общий ресурс - в данном случае это консоль. Не надо рассматривать данные только чисто как некие переменные, массивы и т.п. В моём конкретном случае делается то что нужно именно мне. Без синхронизации такой эффект я не получу. Если иными словами, могу и по другому объяснить - консоль это по сути буфер, буфер это данные, что там винда делает с этим буфером - не важно. Но суть такая же. Вам интересно услышать, что нужно синхронизировать данные общие, пожалуйста - данные это буфер консоли. Какие ещё тут могут быть вопросы? 2) Лог файлы ведутся на каждый счёт помимо консоли, а как же без них то??? При желании ведение их легко включается и отключается, но консоль нужна чисто для текущей визуализации происходящего всего, что крутится внутри одного экземпляра квика. 3) Вот только задержки со слипом после вывода это маразм какой-то. Всё работать должно без всяких слипов. 4) И да, функция принт это код, никто не спорит, но только синхронизируется не функция принт, а доступ её или их к общему ресурсы - буферу консоли.
, Не стремлюсь Вас в чем-то убедить или спорить с Вами. ------------------------- Рассказал Вам свой опыт, так как Вы задали вопрос на форуме. ------------------------------------ Делайте как хотите.
