Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Проблемы с многопоточностью "Клиенты-Сервер"  (Прочитано 23859 раз)
0 Пользователей и 1 Гость смотрят эту тему.
yudjin
Помогающий

ua
Offline Offline
Пол: Мужской

« : 29-04-2011 06:29 » 

Доброе утро. Давно мучаюсь с такой проблемой.
Есть класс - назовем его Сервер, к которому обращаются из разных потоков Клиенты.
Необходимо спроектировать общение Клиента с Сервером таким образом, чтобы Сервер, получив запрос от одного Клиента, обработал его (в это время остальные Клиенты в своем потоке ждут очереди), и затем начал обрабатывать следуюшего Клиента и т.д.
Пробовал в классе Сервер обарачивать тело каждого паблик метода в lock(this) {}. Но происходила "самоблокировка"
Может потому, что эти методы вызывают друг друга?

Слаб в вопросе многопоточности, это мой первый опыт с ней. Собственно вопрос: какое существует архитектурное решение? Что почитать по этому поводу? Классы клиентов будут расти, и соответственно не хотелось бы блокировку возлагать на них.

Приаттачил схему, если это как-то поможет прояснить ситуацию.


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

* Copy of New Bitmap Image.PNG (11.58 Кб - загружено 1758 раз.)
« Последнее редактирование: 29-04-2011 06:40 от yudjin » Записан
Алексей++
глобальный и пушистый
Глобальный модератор

ru
Offline Offline
Сообщений: 13


« Ответ #1 : 29-04-2011 13:49 » 

лично мне ни по описанию, ни по схеме ничего не понятно Улыбаюсь
Записан

Dimka
Деятель
Модератор

ru
Offline Offline
Пол: Мужской

« Ответ #2 : 29-04-2011 14:58 » 

Архитектура должна быть двухуровневой.

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

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

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

Программировать - значит понимать (К. Нюгард)
Невывернутое лучше, чем вправленное (М. Аврелий)
Многие готовы скорее умереть, чем подумать (Б. Рассел)
LightSin
The question title sounds to me the same as "Convert banana into a pistol"... :-)
Постоялец

ru
Offline Offline
id/fm105


« Ответ #3 : 14-06-2012 06:34 » 

помойму делал что то похожее, для каждого клиента создавался поток, средствами winapi симофоры кажется делал область кода с поочередным доступом.. вызывается функция с параметрами и внутри код который может исполнять только 1 поток...
Код:
CRITICAL_SECTION cs;
.... , ,  . . .
DWORD  WINAPI  SocketHandler(void*);
.... , ,  . . .
void clconfis(char *FIO, int *Nttime, int *Ntic,int *Nstudnt, player **studnt, in_addr *ip, int *Qn){
 EnterCriticalSection(&cs);
  bool a=0;
.... , ,  . . .
 LeaveCriticalSection(&cs);}

main()....
  InitializeCriticalSection(&cs);
Записан

Lost in the jungle: 1c, PIC AVR, C++, Python flask, (no Java) JS . for fun: Live For Speed S2 Drift Edition, TeeWorlds
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #4 : 14-06-2012 06:41 » 

LightSin, речь о дедлоках.

Кстати, "семафор".
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.

Хз, я не очень просто не очень во всё это верю, во всякие там сатурны и прочую поебень.
Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines