Управление несколькими счетами - страница 2
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Напрягло вот это:
"If a mutex is abandoned, the thread that owned the mutex did not properly release it before terminating. In this case, the status of the shared resource is indeterminate, and continuing to use the mutex can obscure a potentially serious error."
Я понял так- если приложение убьется во время владения мутексом, то дальше может быть что угодно.
Спасибо за ответ! :-) А можно я тогда задам вопрос "еще дальше" :-).
Например, у меня есть приложение- источник. А к нему- несколько приложений- приемников.
И когда у источника появляются данные- он долже сообщить всем о них,
а когда приемники закончат обработку- они должны сообщить, что они все вышли.
Такого плана модель я представить не могу :-). Можете подсказать,
как это сделать без рассылки сообщений tcp/ip, windows broadcast :-D, etc. ?
P.S.: если 2 стороны- вероятно, я могу представить, как это сделать 2-мя event'ами... )
Спасибо за ответ! :-) А можно я тогда задам вопрос "еще дальше" :-).
Например, у меня есть приложение- источник. А к нему- несколько приложений- приемников.
И когда у источника появляются данные- он долже сообщить всем о них,
а когда приемники закончат обработку- они должны сообщить, что они все вышли.
Такого плана модель я представить не могу :-). Можете подсказать,
как это сделать без рассылки сообщений tcp/ip, windows broadcast :-D, etc. ?
P.S.: если 2 стороны- вероятно, я могу представить, как это сделать 2-мя event'ами... )
Локально или в сети . Это важно.
С использованием объектов синхронизации- т.е. локально. tcp/ip для сети уже есть :-).
Т.е. я не понимаю логику как это все должно "полететь".
Например: если два приложения, то источник выставляет событие "КлиентПроснись"
и ждет событие "КлиентЗакончил". Клиент соответственно выставляет его когда закончит.
А если несколько? А то и правда есть у меня пробел какой-то.
С использованием объектов синхронизации- т.е. локально. tcp/ip для сети уже есть :-).
Т.е. я не понимаю логику как это все должно "полететь".
Например: если два приложения, то источник выставляет событие "КлиентПроснись"
и ждет событие "КлиентЗакончил". Клиент соответственно выставляет его когда закончит.
А если несколько? А то и правда есть у меня пробел какой-то.
Эээ.. WaitForMultipleObjects?
http://msdn.microsoft.com/en-us/library/ms687025(VS.85).aspx
Эээ.. WaitForMultipleObjects?
CriticalSection cs; CLock lock(cs); ... ибо исключения не дремлют :-)
Если локально . Каждый приёмник имеет семафор (можно мютекс). Когда появилось информация у источника,источник переворачивает семафор,если он не занят. Источник имеет FM с информацией её приёмники читают в режиме read . После прочтения или обработки приёмники переворачивают семафор. Думаю,что примерно так.
По факту... это ж все должны друг о друге знать, как-то вхитрую обмениваться информацией на тему того,
у кого какие будут именованные объекты, а потом еще как-то прозрачно намекать кто выходит и перегружается-
чтобы не взращивать объекты, которые ни к чему не присоединены :-).
В этой ситуации если кто-то не "перевернул" семафор означает, что программа повисла, задержалась или кончилась :-).
Да и WaitForMultipleObjects(ждиВсех) при определенных обстоятельствах зависает навечно.
Я высказал несколько возражений против объектов синхронизации- можете ли возразить?
MSDN знаем и любим :-). Правда, все больше по части критической секции и исключительно в форме
CriticalSection cs; CLock lock(cs); ... ибо исключения не дремлют :-)
Ну линк, это так, для порядка :D
Просто это должно помочь, судя по постановке задачи.
Ну и INFINITE в милисекундах тоже не надо ставить, факт... ждать определенное время, после чего действовать по обстоятельствам.
Мне доводилось собирать нечто подобное с большим кол-вом мютексов (имена были динамические ...+Symbol()),работало очень стабильно . Того о чём вы пишете даже не замечал. Просто нужна правильно построенная логика . Когда открыть,когда закрыть и т.п. Доказывать не буду, проще взяться и написать.
Что же касается TCP/IP, я считаю,что глупо связываться с самим собой по телефону,да ещё и с кодированием (Аллегория).
Сообщения можно посылать,но это слишком примитивно.
Итог (моё мнение). Вариант обмена инф. при помощи FM с синхронизацией мютексами (семафорами) это единственный правильно действующий и быстрый вариант обмена данными между приложениями на локальной машине. Что важно обмениваться можно в любую сторону и любых приложений друг с другом.