потоки? помогите ещё раз

[ann_nef]

Собралась в отпуск, а тут задачу подогнали. Пока не знаю как решать, только смутно представляю.

Задача такая:

Надо читать из прибора, из его 3 внутренних буферов по 512 байт информацию и выводить в свою часть экрана.
До тех пор пока на экране не будет нажата, к примеру, кнопка.

Информация в буферах всё время пишется с 0 до 511, и опять с 0.

Создавать 3 потока?
Вывод на экран через CEDIT медленный, как по-другому?

Джон, Алексей153 и все-все-все помогите А то вдруг в отпуск не отпустят

[darkelf]

ann_nef, а зачем тут потоки? в простейшем случае:
пока (не нажата кнопка на экране) цикл
  читаем первый внутренний буфер прибора
  выводим информацию в область экрана для первого буфера прибора
  читаем второй внутренний буфер прибора
  выводим информацию в область экрана для второго буфера прибора
  читаем третий внутренний буфер прибора
  выводим информацию в область экрана для третьего буфера прибора
конец цикла

[ann_nef]

Может и так. Тем более, что бесконечное обновление-запись буферов скорее всего заменится конечным, как я только что выяснила у начальника.

Добавлено через 1 час, 20 минут и 58 секунд:
И всё-таки надо использовать сообщения и\или потоки.
Запустили n-раз сценарий, получили ответ,который <512 байтов --> вывели информацию на экран --> запустили сценарий и тд

[Вад]

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

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

[RXL]

У меня вопрос: как узнать, что устройство изменило буфер и как найти измененные байты? Или буфер рассматривается как единая сущность и каждый раз считывается целиком?

[Джон]

Отпуск - это святое. Конечно поможем.

ann_nef, что значит "Вывод на экран через CEDIT медленный"?

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

Итак, начнём с одного буфера (ессно, что два остальных будут работать аналогично). Вопрос "как узнать" уже RXL задал, поэтому повторяться не буду. В любом случае у тебя есть два варианта: 1. приходит некое сообщение об изменении состояния буфера (возможно даже с доп. инфой); 2. ты сама периодически опрашиваешь буфер, на предмет изменения состояния (тн polling).

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

Ну как-то так. Для более детального ответа не хватает... деталей в вопросе.

[ann_nef]

По мере разговоров с постановщиком задачи, задача несколько упрощается.

Как сформулировал RXL: " буфер рассматривается как единая сущность и каждый раз считывается целиком".

Т.е. всё сводится к такому алгоритму без деталей:
1. запуск сценария
2. задержка длительностью необходимой для получения ответа и заполнения буферов(это время мне известно)
3. чтение буфера
4 вывод буфера
5 переход к п.1
И так продолжается до тех пор пока не нажмут на кнопку "Прекратить".

Сейчас у меня остался вопрос только как событие "нажатие кнопки" сделать условием цикла.

[RXL]

ann_nef, вопросы:
1. Все три буфера заполняются одновременно?
2. Период чтения буферов лимитирован?
3. Периодичность цикла наполнения/чтения всех буферов лимитирована?
4. Интерфейс с устройством какой?

[ann_nef]

RXL, ответы:
1. Все три буфера заполняются одновременно - это ответ по трём CAN каналам.
2. нет
3. нет
  сценарий запускается однократно, через какое-то время получается ответ и можно с ним работать до следующего запуска сценария, инфа в буфере до след.запуска не меняется.
4. устройство подключено к сом-порту.

Но, к устройству подключена плата, которая тестируется, и она отвечает на сценарий, а эти ответы фиксирует уст-во, записывая во внутренние буферы ПЛИС.
А  с устройством через СОМ-порт общается моя программа.


Если не вдаваться в подробности и абстрагироваться от конкретной задачи ,то всё сводится к двум проблемам:

1. как прекратить бесконечный цикл
2. что лучше использовать для вывода экран CEDIT, CListBox

1 вопрос - главный.

[Sla]

1. как прекратить бесконечный цикл

По нажатию кнопки
типа
while (!kbhit()) {

...
}

Добавлено через 6 минут и 33 секунды:
Конечно, это и правильно и неправильно.
Правильно, если программа занимается только  считыванием и выводом.

Неправильно - если еще что-то делается.

В неправильном случае нужно взводить свой собственный флаг

Если говорить о независимых потоках

1. Функция обработки  нажатия клавиши. Взводим флаг
2. Функция чтения буфера
   Проверка флага
       Или прекратить сразу, или закончить ввод
3. Функция вывода
   проверка флага
       Или прекратить сразу, или закончить вывод

[ann_nef]

Sla,
while (!kbhit()) {

...
}

не подходит

[Вад]

ann_nef, а зачем, всё-таки, бесконечный цикл?

[Джон]

1. как прекратить бесконечный цикл
2. что лучше использовать для вывода экран CEDIT, CListBox

1 вопрос - главный.

1.
Судя по некоторым вторичным половым признакам (CEDIT, CListBox) у тебя какое-то MFC-шное оконное приложение, хотя лучше всего это явно указывать с самого начала, тогда не будт непоняток типа kbhit().
Итак, у тебя крутится цикл, и ессно вся программа "спит". Обработка сообщений невозможна. Даже, если ты нажимаешь кнопки, их сообщения помещаются в очередь, но из неё не достаются и не обрабатываются. Для этого есть такой трюк. Допустим в обработчике OnKeyDown (или по нажатию кнопки, или по какому другому событию) ты устанавливаешь некий флаг член класса m_bMyKeyDown = TRUE, тогда:

Код: (C++)

        MSG msg;
        m_bMyKeyDown = FALSE; // сбрасываем флаг
        while( !m_bMyKeyDown )
        {
                // тело цикла
                // ...


               // чуть не забыл - может потребуется дать команду обновить окошко
               UpdateWindow();
                // трюк!!! - даём возможность обработать накопившиеся сообщения
                while (::PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE)) AfxGetApp()->PumpMessage();
        }

2. Если требуется ну очень большая скорость отображения, то я бы сделал своё окошко, в котором бы отрисовывал данные. Но это ессно требует неких энергетических и временных затрат. Начни с CEdit.

[ann_nef]

Джон, спасибо!
 
Получилось на тестовой программе, с CEDIT том числе. Сейчас буду менять основную программу.
Извините, что не написала , что пишу visual c++ 6 и использую MFC. 

[Джон]

Спасибо скажешь, когда в отпуск отпустят.

[ann_nef]

К сожалению, в боевой программе ничего не получается.
Этот бесконечный цикл поставила в OnInitDialog и результата на экране нет. Чуствую смутно не туда 
Если сделать конечное количество циклов, то информация на экране появляется по окончании всех циклов.
В общем караул!

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

[Sla]

В данном случае нужно показать и цикл и вывод
Кто, где и как

[ann_nef]

Сейчас кусок этот выделю, а то вся программа очень большая.

[RXL]

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

[zubr]

Или в каждой итерации цикла обрабатывать очередь сообщений TranslateMessage, DispatchMessage

[Джон]

К сожалению, в боевой программе ничего не получается.

Я думаю ты просто в торопях что-то упустила. Посмотри ещё раз всё внимательно. С UpdateWindow пробовала?

СТОП!!! только сейчас заметил ключевую фразу: "Этот бесконечный цикл поставила в OnInitDialog". Чесслово я бы удивился, если бы ТАК работало. Само название Init уже подразумевает отсутствие каких либо иных действий, кроме инициаллизации.

Значит так. Быстренько добавляешь таймер на 100-250 мс, и запускаешь его в OnInitDialog. А уже по таймеру вызываешь ф-ю с циклом. Таймер ессно тут же убиваешь.

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

Ром, для этого и существует трюк, который я привёл. Всё прекрасно работает.

[Вад]

Значит так. Быстренько добавляешь таймер на 100-250 мс, и запускаешь его в OnInitDialog. А уже по таймеру вызываешь ф-ю с циклом. Таймер ессно тут же убиваешь.

Кстати, а просто в обработчике какого-нибудь WM_CREATE это можно сделать?

[Sla]

А нельзя это цикл вынести куда-то отдельным потоком (процессом)?

[zubr]

начит так. Быстренько добавляешь таймер на 100-250 мс, и запускаешь его в OnInitDialog. А уже по таймеру вызываешь ф-ю с циклом. Таймер ессно тут же убиваешь.

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

[Джон]

Кстати, а просто в обработчике какого-нибудь WM_CREATE это можно сделать?

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

А нельзя это цикл вынести куда-то отдельным потоком (процессом)?

Слав, в принципе можно, но только всё-равно этот поток (процесс) должет отслеживать готовность (в данном случае - завершение создания) окна, или же запускаться после создания. Хрен редьки не слаще. Ибо нет смысла пытаться показать информацию в окне, которое ещё не создано, и/или контролы которого ещё не созданы.

Добавлено через 3 минуты и 56 секунд:

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

Как это? Почему? Я ж это не от фонаря написал. Я использовал это уже много раз в своих проектах. Всё прекрасно работает. Это стандартная нормальная асинхронная развязка. При создании окна (в данном случае при инициаллизации) запускается таймер. Сообщение таймера придёт после. По таймеру запускается ф-я с бесконечным (или с конечным) циклом. Какие проблемы? Зачем выполнять итерации цикла по таймеру?

[Sla]

готовность (в данном случае - завершение создания) окна
должен осуществлять модуль вывода

один "поток" читает буфера
второй - выводит
Третий занимается строительством "окон" и основой цикл.

[Джон]

Слав, а зачем так сложно? Что значит модуль ввода? Есть приложение типа диалог, в этом диалоге должна отображаться опрашиваемая в цикле информация. Она должна отображаться в окне, те после его создания. Два потока для чтения/отображения необходимы, как я уже говорил выше, для большого количества данных и быстрой скорости отображения. Я такую штуку делал для сканеров, они там выплёвывают данных мегабайтов 5 в сек. Вот тогда да. FIFO буфер, свой контрол отображения. В данном случае это будет из "Бука" по комарам.

[zubr]

Как это? Почему? Я ж это не от фонаря написал. Я использовал это уже много раз в своих проектах. Всё прекрасно работает. Это стандартная нормальная асинхронная развязка. При создании окна (в данном случае при инициаллизации) запускается таймер. Сообщение таймера придёт после. По таймеру запускается ф-я с бесконечным (или с конечным) циклом. Какие проблемы? Зачем выполнять итерации цикла по таймеру?

Джон, ты уверен? Я попробовал у себя так сделать, правда в дельфях, но не вижу разницы. Сделал таймер, который включается через 10 сек, а в обработчике таймера его отключаю и запускаю бесконечный цикл. Таймер устанавливаю в обработчике OnCreate формы. Приложение запускается, в течение этих 10 сек отвечает на действия пользователя, после чего закономерно зависает.

[Sla]

1. Мы не знаем количества данных (начальный топик не показатель)
2. Не увидел "Бука" Разделение задач (потоков) где ж там "Бука"?

Работа по таймеру - можно только в качестве проверки "концепции" работоспособности.


кстати

Цикл чтения буферов
  тело цикла
  UpdateWindow();
...
причем "Цикл чтения буферов" это условно, не надо
Т.е. бесконечный цикл ожидания нажатия
чтение буферов, можно проводить не постоянно, а только, например каждые nnn мсек (проверять это в процедуре чтения)
соответственно настраивать и вывод

[Джон]

zubr, уверен . "Я не знаю как у Вас там в Стамбуле (Дельфях)" почти (с), но в С++ сделаю пример. Только не сейчас. Коропоратив - святое дело. Я ща дома, через минут 10 выдвигаемся, как только семья будет готова, потом я в бюро заскочу, если будет время - сделаю, если нет, то завтра или в ближайшем будущем.

Приложение запускается, в течение этих 10 сек отвечает на действия пользователя, после чего закономерно зависает.

А вот это ты делал?

Или в каждой итерации цикла обрабатывать очередь сообщений TranslateMessage, DispatchMessage

Насколько я понял, это древнегреческий эквивалент "моему" трюку.

Слав,

1. Почему не показатель? Это поставленная задача - 512 байтов.
2. Все уже вроде решилось и в тестовом проекте работает как надо. Насколько я понял, проблема теперь в рабочей проге. Так и эта проблема решается 5 строчками кода.



Добавлено через 2 часа, 1 минуту и 45 секунд:
Как говорят у нас  : "bitteschön"

Код: (C++)

BOOL CTestUpdateDlgDlg::OnInitDialog()
{
        CDialog::OnInitDialog();

        SetIcon(m_hIcon, TRUE);
        SetIcon(m_hIcon, FALSE);

        SetTimer(MY_TIMER, 50, NULL);

        return TRUE;
}

void CTestUpdateDlgDlg::OnBnClickedOk()
{
        m_bMyStop = !m_bMyStop;

        if(!m_bMyStop)
        {
                SetTimer(MY_TIMER, 50, NULL);
        }
}

void CTestUpdateDlgDlg::OnTimer(UINT nIDEvent)
{
        if(MY_TIMER == nIDEvent)
        {
                KillTimer(MY_TIMER);
                GetDlgItem(IDOK)->SetWindowText(_T("Stop"));
                RunLoop();
        }
        CDialog::OnTimer(nIDEvent);
}

void CTestUpdateDlgDlg::RunLoop()
{
        MSG msg;
        m_bMyStop = FALSE;
        int i=0;
        while( !m_bMyStop )
        {
                CString stBuf;
                stBuf.Format(_T("%d"), i++);
                GetDlgItem(IDC_EDIT1)->SetWindowText(stBuf);
                if(i>100) i=0;
                while (::PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE)) AfxGetApp()->PumpMessage();
        }
        GetDlgItem(IDOK)->SetWindowText(_T("Start"));
}