forum.clarionlife.net

finsoftrz писал(а): 14 Декабрь 2017, 15:11Я их использую при управлении окнами.

O ! А расскажите пожалуйста как ? Может и мне оно надо ....

Сто лет не касался. В принципе, в доке по clarion6 должно быть все подробно расписано.
У меня объявляется класс
FsCritSect CriticalSection
А потом в нужных местах код обрамляется в скобки:
FsCritSect.Wait()
<код>
FsCritSect.Release()

kreator писал(а): 14 Декабрь 2017, 14:38

finsoftrz писал(а): 14 Декабрь 2017, 13:41 Да, mdi в кларионе очень удобная и функциональная вещь.

Я по-другому воспринимаю. Принцип работы MS Word, к примеру, мне больше нравится. Те же окна, только как бы отдельные процессы. Например, есть такая тема. Нужно вместе с основным MDI-окном открыть ещё одно, типа дочернее к нему, которое будет висеть поверх родительского и нужно обеспечить их взаимодействие. Что я для этого делаю? Объявляю дочернее non-MDI и вызываю его стартом. Другого приемлемого варианта не нашёл. Всё хорошо. Только до тех пор, пока пользователь не захочет открыть другое MDI-окно.

Самая простая схема взаимодействия между двумя mdi окнами - через класс. То есть создаем экземпляр класса в первом потоке, стартуем второй, передав ему в качестве параметра адрес этого класса. Затем можем что-то делать со свойствами этого класса из обоих потоков. Чего-то записали в свойства класса в одном потоке, пнули пользовательским событием другой, чтобы тот тоже что-то сделал и т.д.

finsoftrz писал(а): 14 Декабрь 2017, 16:06 пнули пользовательским событием другой

Это мы можем и без класса ... Семафоры - это несколько другое ...
Например разделили расчёт аналитики на два потока. Первый закончил расчёт и ждёт второй.
Дождался - слили результаты в общий список и запустили печать расчёта и т.д.

Смысл использования класса в том, чтобы образовать общую область данных, которые могут использовать разные потоки.
Насчет семафора не понял. Это в abc так понимается? Я думал, что речь про обычные семафоры, с помощью которых в винде управляется выполнение участков кода в разных потоках. Интерфейс к ним был сделан в clarion6, когда перешли от эмуляции потоков к использованию нативных потоков.

Так. Похоже мы о разном .... Получилось, что в одной деревне всех звали Буратино ...
Я говорю о т.к. называемых Synchronization Object см. в справке Clarion поиск по: CWSYNCHC

Игорь Столяров писал(а): 14 Декабрь 2017, 17:25Так. Похоже мы о разном .... Получилось, что в одной деревне всех звали Буратино ...
Я говорю о т.к. называемых Synchronization Object см. в справке Clarion поиск по: CWSYNCHC

Я вроде тоже...

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

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

Запросы они передают третьему потоку, который пишет их в БД и отправляет команды
потоку, который печатает полученные чеки из БД на ФР.
И всё это должно работать согласованно, с общими данными, одновременно. Как-то так ...

А в чем проблема?

Тут надо смотреть в сторону сокетов...

finsoftrz писал(а): 14 Декабрь 2017, 18:02Тут надо смотреть в сторону сокетов...

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

Я не очень вижу в контексте данной задачи рассматриваемую науку. Есть сервис, например, через который идут коннекты с удаленных компьютеров. В рамках этих коннектов происходит запись в базу данных и получение результата, что чек напечатан. А отдельная утиля печатает чеки и формирует квитанцию о выполнии. По идее, такое должно работать железобетонно.

finsoftrz писал(а): 14 Декабрь 2017, 18:29А отдельная утиля печатает чеки и формирует квитанцию о выполнии. По идее, такое должно работать железобетонно.

Да, вот оно ! Теперь всё верно. Вы просто вопрос обеспечения одновременного функционирования задач перекладываете на
многозадачность Windows. Так проще и хорошо, если если задания можно разделить (одно принимает, а второе печатает).
А если нет ? Если задания должны функционировать в единном приложении с общей адресацией памяти и разделением ресурсов ?
Вот тут и появляются семафоры ...

В смысле, обязательно используя нетредные переменные? Что-то я туго соображать стал, все погода виновата...

finsoftrz писал(а): 14 Декабрь 2017, 20:46обязательно используя нетредные переменные

Как я понимаю: если у потоков есть некая область общего адресного пространства в памяти - то это и есть
нетредные переменные. В идеале - статические, но не обязательно.