Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Система";
Текущий архив: 2003.04.03;
Скачать: [xml.tar.bz2];

Вниз

Общие ресурсы для нескольких потоков.   Найти похожие ветки 

 
serg_1   (2003-02-05 14:18) [0]

Доброго времени суток!

В процессе разработки многопоточного приложения (некий сервер) столкнулся со следующей проблемой. Всвязи с тем, что предварительные результаты отработки потоков (по запросу от клиентов) иногда одинаковы имеет смысл получить этот результат в одном из потоков, а в остальных дождаться его получения (не расходуя при этом процессорного времени на ту же работу). Ничего кроме банального while Flag do FApplication.ProcessMessages (FApplication: TApplication передается в поток) в голову не приходит. Имхо как-то не очень красиво. Посоветуйте плз более "красивую" реализацию подобного случая. Сервер корбовский, разрабатывается с помощью Delphi7. Заранее спасибо.


 
Reindeer Moss Eater   (2003-02-05 14:25) [1]

Семафор подходит лучше всего


 
Слесарь Матерящийся   (2003-02-05 15:20) [2]

Используйте критические секции. Наиболее правильное решение. Остальные спорны.
(CRITICAL SECTIONs)


 
serg_1   (2003-02-05 16:19) [3]

2Слесарь Матерящийся
Они, к сожалению, не очень удобны. Поскольку решение о выполнении или ожидании нужно принимать на ходу.

2Reindeer Moss Eater
Наверное это то что нужно, но я к сожалению никогда раньше с семафорами не работал. Не могли бы вы привести пример или дать ссылку?


 
serg_1   (2003-02-07 10:50) [4]

2All
Неужели никто с семафорами не работал?! Поделитесь плз примерами%)


 
Reindeer Moss Eater   (2003-02-07 10:56) [5]

Критические секции как раз менее всего подходят.
Поток, создавший ресурс и завершивший с ним работу должен знать, можно ли его уничтожать, или нет. (Начали ли его использовать другие потоки)


 
serg_1   (2003-02-07 19:05) [6]

Особенность сервера такова, что поток иногда может создать ресурс, но уничтожать его не будет (ресурсы уничтожаются по завершению работы сервера), вот %)


 
Reindeer Moss Eater   (2003-02-07 19:13) [7]

Логика работы сервера очень туманна.
Не будет уничтожать ресурс до завершения работы
Значит актуальность созданного ресурса не ограничена по времени?
Значит для его "постройки" не обязательно ждать запроса клиента?
Значит потокам не обязательно самим создавать эти ресурсы, а использовать созданные при запуске сервера?
Слишком много неясностей для того, что бы что либо рекомендовать. Тем более из разряда "красивых" решений.


 
serg_1   (2003-02-10 10:56) [8]

Извиняюсь за туманность вопроса, честно скажу хотел задать его попроще:). Если вдаваться в детали, то необходимо написать корбовский сервер (он по умолчания многопоточный) который обрабатывал запросы клиентов. Под ресурсом понимается некая струкура (что-то типа динамического массива). Процесс создания подобной структуры довольно трудоемек (потому создается динамически по требованию). Число возможных (не факт что в процессе работы все будут нужны) ресурсов не более 200. Для отработки сервером клиентского запроса серверу необходим определенный ресурс. Если ресурс не был создан, то он создается. Если ресурс создан, то на него просто передается ссылка. Интересующий меня вопрос касается случая, когда ресурс не был создан, а со стороны клиентских приложений приходят несколько запросов по работе с ним. Мне кажется логичным, что в подобном случае логично было бы создавать ресурс в одном потоке, а в других просто дожидаться пока первый поток не закончит создания ресурса.
Отвечая на Ваши вопросы:
Значит актуальность созданного ресурса не ограничена по времени?
Да, ресурсы уничтожаются при завершении работы сервера.
Значит для его "постройки" не обязательно ждать запроса клиента?
Нет, не обязательно. Но поскольку число ресурсов довольно велико (200), создание ресурса довольно трудоемкая задача, вероятность того что потребуются все возможные ресурсы довольно мала, гарантировать на момент создания сервера (да фактически в любой момент его работы) что необходим данный список ресурсов нельзя, то (имхо) имеет смысл создавать ресуры динамически и удалять их по завершению работы сервера.
Значит потокам не обязательно самим создавать эти ресурсы, а использовать созданные при запуске сервера?
Ответил в предыдущем вопросе:)


 
Reindeer Moss Eater   (2003-02-10 11:23) [9]

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


 
serg_1   (2003-02-10 13:41) [10]

Не совсем так (видимо все еще имеется наличие присутствия тумана :)). Скажем запросы от клиента могут быть вида дай статистику по городу Москве - function GetStatInfo(const AArea: integer): TSomething. Чтобы подсчитать эту статистику серверу нужен ресурс со статистическими данными по Москве (TStatDataArray[AArea], TStatDataArray = array of TStatData). Если TStatDataArray[AArea] не проинициализирован, то его нужно инициализировать (в предыдущих постах называлось создать ресурс). Операция инициализации (создания) занимает много времени (да и жрет памяти весьма прилично). По каким городам (AArea) понадобится статистическая информация неизвестно. Имхо логично инициировать массив TStatDataArray по запросу от клиента. Проблема в одновременной инициализации несколькими потоками статистической информации по одному городу (иначе инициализации несколькими потокомами TStatDataArray[AArea1],..,TStatDataArray[AAreaN], где AArea1=..=AAreaN). Вот:)


 
Reindeer Moss Eater   (2003-02-10 14:33) [11]

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



Страницы: 1 вся ветка

Форум: "Система";
Текущий архив: 2003.04.03;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.48 MB
Время: 0.009 c
7-6833
xfrost
2003-02-08 15:30
2003.04.03
Как выключить


4-6849
ik
2003-02-05 17:25
2003.04.03
BackGround на форме ???


3-6306
Pirat
2003-03-15 21:27
2003.04.03
BDE(FoxPro) : BLOB поле портит данные ?!


14-6787
Malder
2003-03-16 23:05
2003.04.03
Просмотр DLL


14-6675
sapsi
2003-03-18 08:24
2003.04.03
Отношение к новым





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский