Как называется способ обмена данными между пользователем и программой
Перейти к содержимому

Как называется способ обмена данными между пользователем и программой

  • автор:

Как называется способ обмена данными между пользователем и программой?

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

Этот способ двустороннего обмена данными между человеком и машиной (компьютером, смартфоном и проч.) принято называть двумя словами — пользовательский интерфейс (UI — User Interface).

автор вопроса выбрал этот ответ лучшим

Как называется способ обмена данными между пользователем и программой

В ЭВМ применяются три режима ввода/вывода: программно-управляемый ВВ (называемый также программным или нефорсированным ВВ), ВВ по прерываниям (форсированный ВВ) и прямой доступ к памяти. Первый из них характеризуется тем, что инициирование и управление ВВ осуществляется программой, выполняемой процессором, а внешние устройства играют сравнительно пассивную роль и сигнализируют только о своем состоянии, в частности, о готовности к операциям ввода/вывода. Во втором режиме ВВ инициируется не процессором, а внешним устройством, генерирующим специальный сигнал прерывания. Реагируя на этот сигнал готовности устройства к передаче данных, процессор передает управление подпрограмме обслуживания устройства, вызвавшего прерывание. Действия, выполняемые этой подпрограммой, определяются пользователем, а непосредственными операциями ВВ управляет процессор. Наконец, в режиме прямого доступа к памяти, который используется, когда пропускной способности процессора недостаточно, действия процессора приостанавливаются, он отключается от системной шины и не участвует в передачах данных между основной памятью и быстродействующим ВУ. Заметим, что во всех вышеуказанных случаях основные действия, выполняемые на системной магистрали ЭВМ, подчиняются двум основным принципам.
1. В процессе взаимодействия любых двух устройств ЭВМ одно из них обязательно выполняет активную, управляющую роль и является задатчиком, второе оказывается управляемым, исполнителем. Чаще всего задатчиком является процессор.
2. Другим важным принципом, заложенным в структуру интерфейса, является принцип квитирования (запроса — ответа): каждый управляющий сигнал, посланный задатчиком, подтверждается сигналом исполнителя. При отсутствии ответного сигнала исполнителя в течение заданного интервала времени формируется так называемый тайм-аут, задатчик фиксирует ошибку обмена и прекращает данную операцию.

Программно-управляемый ввод/вывод

Данный режим характеризуется тем, что все действия по вводу/выводу реализуются командами прикладной программы. Наиболее простыми эти действия оказываются для «всегда готовых» внешних устройств, например индикатора на светодиодах. При необходимости ВВ в соответствующем месте программы используются команды IN или OUT. Такая передача данных называется синхронным или безусловным ВВ.

Однако для большинства ВУ до выполнения операций ВВ надо убедиться в их готовности к обмену, т.е. ВВ является асинхронным. Общее состояние устройства характеризуется флагом готовности READY, называемым также флагом готовности/занятости (READY/BUSY). Иногда состояния готовности и занятости идентифицируются отдельными флагами READY и BUSY, входящими в слово состояния устройства.

Процессор проверяет флаг готовности с помощью одной или нескольких команд. Если флаг установлен, то инициируются собственно ввод или вывод одного или нескольких слов данных. Когда же флаг сброшен, процессор выполняет цикл из 2-3 команд с повторной проверкой флага READY до тех пор, пока устройство не будет готово к операциям ВВ (рис. 3.10). Данный цикл называется циклом ожидания готовности ВУ и реализуется в различных процессорах по-разному.

Рис. 3.10. Цикл программного ожидания готовности внешнего устройства

Основной недостаток программного ВВ связан с непроизводительными потерями времени процессора в циклах ожидания. К достоинствам следует отнести простоту его реализации, не требующей дополнительных аппаратных средств.

9.1. Способы обмена данными между устройствами

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

Программно-управляемый обмен данными осуществляется при непосредственном участии и под управлением МП.

Данные между основной памятью и периферийным устройством (ПУ) пересылаются через МП:

Операция ввода-вывода инициируется текущей командой прог-

раммы или запросом прерывания от периферийного устройства.

В любом случае МП выполняет специальную подпрограмму ввода-

вывода, отвлекаясь от выполнения основной программы.

Программно-управляемый способ может быть эффективен только

для операций ввода-вывода отдельных байт (слов) и поэтому используется для обмена данными между МП и другими устройствами вычислительной системы.

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

В результате скорость передачи данных окажется недостаточной для работы с высокоскоростными периферийными устройствами (например, с ЗУ на дисках и барабанах, с АЦП и т.п.). Более того, эта скорость может оказаться вообще неприемлемой для систем, работающих в реальном масштабе времени.

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

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

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

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

Прямым доступом к памяти управляет контроллер ПДП. При этом возможно использование как общей, так и отдельной шины для связи с памятью:

Контроллер ПДП выполняет следующие функции:

а) управление инициируемой МП или ПУ передачей данных между ОП и ПУ;

б) задание размера блока данных, который подлежит передаче, и области памяти, исполь- зуемой при передаче;

в) формирование адресов ячеек ОП, участвующих в передаче;

г) подсчёт числа единиц данных (байт, слов), передаваемых от ОП в ПУ или обратно, и определение момента завершения заданной операции ввода-вывода.

Структурная схема контроллера ПДП включает один или несколько буферных регистров РгБ, регистр-счётчик текущего адреса данных РгТАД, счёт-чик текущих данных СчТД и устройство управления УУ.

При инициировании операции ввода-вывода в СчТД заносится размер передаваемого блока (число байт или слов), а в РгТАД – начальный адрес используемой области памяти.

С передачей каждой единицы блока содер- жимое РгТАД увеличивается на 1. При этом формируется адрес очередной ячейки ОП, учас- твующей в передаче.

Одновременно уменьшается на 1 содержи- мое СчТД.

Обнуление СчТД указывает на завершение передачи.

Контроллер ПДП по сравнению с микропроцессором обычно имеет более высокий приоритет в занятии цикла памяти.

Управление памятью переходит к контроллеру ПДП сразу после завершения цикла её работы, выполняемого для текущей команды МП.

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

Как организовать обмен данными между приложениями?

Есть, положим, 2 программы (2 процесса). Как организовать между ними обмен данными в рамках одной машины (можно и не ограничиваться)?
Пишу без конкретики потому как хотелось бы получить максимально универсальное решение. Т. е. например, есть на Delphi написанная программа; есть, скажем, сервер на Node.js; есть какая нибудь еще софтина — каким образом можно организовать обмен данными между этим разнородным зоопарком?

  • Легкий (в теории) переход от соединения 2 процессов в рамках 1 машины к соединению через сеть
  • Кроссплатформенность
  • Широкая поддержка этой технологии
  • Не окажутся ли сокеты бутылочным горлошком в плане быстродействия?
  • Насколько это «костыльное» решение для межпроцессорного общения?
  • Какие есть альтернативы?
  • Вопрос задан более трёх лет назад
  • 10176 просмотров

Комментировать
Решения вопроса 0
Ответы на вопрос 5
Дмитрий Ковальский @dmitryKovalskiy
программист средней руки

Решение в лоб — создать общий ресурс для всех приложений. К примеру xml или маленькая база SqlLite. И пусть обе апликухи оттуда читают. Или вы хотите именно взаимные «пинки» заставляющие что-то делать?

Ответ написан более трёх лет назад
Interface @Interface Автор вопроса

Хотелось бы, что б это все было как можно быстрее. Не хочется обращаться к диску вовсе. Xml — это несколько другой уровень абстракции, мне нужно средство чем этот xml гонять туда-сюда. Пинки, если я вас правильно понял, тоже нужны. Т.е. один процесс должен «отловить событие» отправки другим процессом данных.

sitev.ru — мой блог .
Я за сокеты!
Ответ написан более трёх лет назад
xmoonlight @xmoonlight
Тогда поясни:
В чем разница: сокета и TCP-порта и именованного канала?)))

xmoonlight: сокет это интрефейс для обмена данными, а tcp вообще протокол, для контроля обмена. Они могут работать как вместе, так не вместе. Что за вопросы?

Saboteur @saboteur_kiev Куратор тега Программирование
xmoonlight: tcp-port это номер порта в IP протоколе.
именованый канал — это файловая абстракция
xmoonlight @xmoonlight
https://sitecoder.blogspot.com
Нет. Решение в лоб — это IPC! )
https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D0%B6%D.
Ответ написан более трёх лет назад
Interface @Interface Автор вопроса

По вашей ссылке сокет является одним из методов IPC, получается сокеты — все таки лобовое решение? Хорошо ли это? 🙂

xmoonlight @xmoonlight

Interface: то что Вы увидели в огромном списке знакомое слово — это хорошо, а вот что сделали такой вывод и посмеялись над собой — плохо.
Смотрите все методы и учите.

xmoonlight: в реальности методов не много:
— пайпы (unix only, на шиндовс боль и унижение)
— сокеты (работает всегда)
— шаред мемори (эффективно, но сложно и можно напороться на кучу грабель)

Все остальное — слишком специфично и подходит только в конкретных случаях. Так что имхо, если нужна кросплатформенность, то только сокеты.

xmoonlight @xmoonlight
Сергей Протько: shared only или смысла даже браться стыковать нет. ИМХО.

xmoonlight: зависит от того насколько интенсивный обмен данными идет. По сути использование сокетов на лупбэк интерфейсе не сильно медленнее шаред мемори, сетевой стэк не задействуется.

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

xmoonlight: ну и да, шансы все запороть с шаред мемори намного выше чем с сокетами.
xmoonlight @xmoonlight
Сергей Протько: ну если руки у кодера кривые — ничего не спасёт. ни сокеты, ни дублирование.

xmoonlight: да ладно вам, руки кривые, зачем специально повышать риски? Все банально упирается в юз кейсы которые мы хотим решить. Сокеты решают 98% задачь затрагивающих IPC эффективно как с точки зрения производительности, так и с точки зрения трудозатрат. Оставшиеся 2% — разработчики таких систем думаю не будут спрашивать на тостере что юзать для IPC.

xmoonlight: для контраста, я имел возможность баловаться со всеми перечисленными способами IPC, сейчас вот пилю медленно но верно менеджер процессов для symfony/process под свои нужды на пайпах. На пайпах Карл (не удержался, клиента зовут так).

xmoonlight @xmoonlight
Сергей Протько: Карл на пайпах? — наверное это круто) (без пояснений — тут никак. )

xmoonlight: ну это мем такой.

1426251502_421820247.jpg

xmoonlight @xmoonlight
Сергей Протько: так. половина понятна, осталось понять какого клиента зовут Карл?)

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

Еще одна загубленная острота.

xmoonlight @xmoonlight

Сергей Протько: «в рамках которого мне понадобилось написать менеджер процессов что бы распаралелить обработку одной простенькой штуки.» — это обман)): либо штука не простенькая, либо можно обойтись без менеджера процессов) есть линк на шедевр?
«Еще одна загубленная острота» — к сожалению, я не владею телепатией, в плане понимания выражения) Возможно, это «тупость»/»необдуманный поступок»?! )

xmoonlight: пока нет, все не дойдут руки допилить вариант который можно показывать людям (в проекте сейчас используется написанный на скорую руку вариант), может на следующей неделе. На данный момент поделка эта умеет только генерировать процессы из итератора с возможностью отслеживания сколько одновременно процессов может быть запущено (в неблокируемом режиме, через proc_open). В планах сделать так же возможность не убивать воркеры и организовать общение с мастером через пайпы, что в принципе не сложно, но на это нужно время. Последнее мне нужно для того что бы сделать свой паралелизатор для бихата, ибо. при подходе с запуском воркеров на каждый чих, у меня половина времени выполнения одного воркера будет занимать его бутстрапинг.

max-kuznetsov

Максим Кузнецов @max-kuznetsov
Главный IT-архитектор

1. Не создавать зоопарк. Ни при каких условиях.
2. Не пытаться найти универсальное решение для всего на свете. Такое решение всегда избыточно, неповоротливо, несопровождаемо, а, главное, никому не понятно. Исходите из конкретных требований и применяйте архитектурные паттерны.
3. Существует много общепринятых технологий обмена данными между компьютерами или между процессами на одном компьютере. Можно реализовать сетевое взаимодействие на низком уровне. Можно использовать уже готовые решения (SOAP, например). Можно использовать посредников (иногда это единственный способ избавиться от влияния зоопарка, созданного другими людьми). Причём посредники тоже бывают разные. Опять-таки, смотрите конкретные требования и паттерны.

Ответ написан более трёх лет назад
Комментировать
Нравится Комментировать

leventov

Насчет «самого универсального» решения — почитайте вот это: tammersaleh.com/posts/the-number-one-trait-of-a-gr.

Зависит от типа взаимодействия. Если это обмен сообщениями, это одно. Берите сокеты или очереди. Если перекачка однотипных данных из процесса в процесс — та же очередь. Если это какое-то более сложное разделяемое состояние, например динамическое множество онлайн-пользователей с какими-то ассоциированными данными (если речь о серверах зашла) — возьмите уже полноценную in-memory базу данных.

Ответ написан более трёх лет назад
Комментировать
Нравится Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

php

  • PHP
  • +3 ещё

Почему не срабатывает ссылка подтверждения регистрации в Symfony 6?

  • 1 подписчик
  • 34 минуты назад
  • 7 просмотров

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *