Асинхронна комуникация, Няколко устройства на обща шина

Точно така.
Ако изпращам само към едно устройство (една команда) то единствения отговор ще е точно от това устройство, точно на тази команда.

Това е ОК но има недостатък - блокираща операция е, защото чака отговор. Обикновено времето за отговор е под 50ms. Ако нацелиш обаче момент когато устройството е заето, отговорът може да даойде и по-късно (дали е заето или не се вижда в събитията, което позволява синхронизация). От друга страна, ако устройството е изключено (или просто го няма) се чака timeout.
По тази причина, работата с шината (устройствата по нея) трябва да се изнесе в отделна нишка за да не блокираш UI-а (или там от където ти върви основната логика, не винаги има UI).

Към момента правя API-то за комуникацията и това ограничение не ми харесва. Затова искам командите да се пращат асинхронно.

Това вече не блокира а отговорът идва в callback-ът applyResponseA. Всъщност, кодът горе е леко непълен

Тук вече има втори callback които обработва грешките (включително и timeout). Това работи ОК при едно устройство.

Но ако се върнен в началото

и приемем, че buffer1 и buffer2 са команди за различни устройства. То вече имаме "едновременно" подаване на команди към различни устройства което налага допълнителната синхронизация на нишката коиято изпраща реално данните и тази която ги чете.

//офф
Самия CompletableFuture е гъвкав и позволява блокиращи извиквания (без да се подава callback) също така позволява верижно свързване на callback функции (много удобно при подаване на логически свързани команди). Затова съм го избрал за основа на API-то

понеже често пиша подобни работи, убедил съм се че по-добре отговора да се чете по таймера, а не в отделна нишка. нишките винаги крият изненада, а с таймер всичко е фасулско и безопасно.
ама можеш да пратиш втора команда преди да е дошъл отговора от първата? ако щеш пращай, ако устройството е заето с първата ще я игнорира, ако не е ще получиш отговора от двете по-късно. това не само не е проблем, а е желателно. нишки пускам само за тежки изчисления, за да ползвам всички ядра, никога като част от дизайна

Имаш един ресурс, който можеш да достъпваш от колкото си искаш нишки, това е TX. Правиш си семафор за него, който използват нишките които искат да го използват. Нишката заема ресурс, прави нещо с него, като свърши го освобождава. Другите чакат да се освободи.

RX си чете нонстоп, ако получи събитие го пъха в опашка на събитията където нишка ги обработва, отговорите се пращат към активната TX нишка. За това ще ти трябва глобален обект дето да показва коя е активната нишка в момента.

Кода дето ще върши това е по-малък от текста дето го изписах тук.

Това мнение е било редактирано от ici на 26-02-2026, 10:57

Прикачена картинка (Кликнете на картинката, за да я увеличите!)

Това се налага ако *блокираш* нишките.

Понеже не разбирам от Java те питам няма ли в тая Java *сигнали*, че има данни за четене/пращане за да *четеш/пишеш* без да блокираш.

Няма връзка между броят нишки и броя на устройствата.
Ако нямаш начин да различаваш отговорите, тогава нямаш начин да пращаш няколко команди едновременно, но и да имаш, нищо не ти пречи да го правиш с една нишка.

Но и да го правиш с блокиране, пак не ти трябват нишки за всяко устройство - пращаш командите една по една, като получиш отговор тогава пращаш следващата.

Сигналите в java са синхронизационни маханизми (блкиране) - wait() чака "сигнал", notify() подава "сигнал" към една от нишките които го чакат и notifyAll() сигнализира всички нишки. Това е заложено по дизайн в платформата и е синхронизация на най-ниско ниво.

На по-високо ниво тия механизми се скриват. Например, кодът горе извиква future.join(). Вътрешно, този метод извиква wait() и чака future обектът да завърши. Когато се получат данни се извиква future.complete(). Този метод освен че изпълнява callback функцията асоциирана с обектът, подава и notifyAll() което нотифицира всички чакащи за тоя сигнал. Тук future обектът се споделя между нишките (защото е различен, асоцииран с всяка отделна команда заради необходимосста да имаме различни callback финкции). Самото споделяне става атомарно (реализирано е в AtomicReferance) макар, че с него може би преигравам, но не пречи.

Това мнение е било редактирано от thrawn на 26-02-2026, 12:13

@dvader, нишките не са за всяко устройство. Общо са 3 (независимо от броя на устройствата):

MainThread (основната нишка - UI-а върви на нея и тя инициализира подаването на командите и актуализира състоянието си в зависимост от отговорите).

CommandThread - изпраща командите (тук се рализира реално изпращането на команда едва след като се получи отговор на предходната команда - коментирания join() е тук. Чакането на команда за изпращане - take() също ползва wait() ако опашката от команди се изпразни). Така и при take() има блокиране, докато не постъпи команда за изпращане.

И третата нишка ReadThread - чете постъпващите данни и извиква callback функциите за събития и отговор на команди. Тук е complete() която нотифицира CommandThread-ът ще командата е получила отговор. И извиква callback-ът за да може MainThread да види/обработи отговорът.

Това мнение е било редактирано от thrawn на 26-02-2026, 13:08