Проблемы с многопоточностью "Клиенты-Сервер"

[yudjin]

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

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

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

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

[Алексей++]

лично мне ни по описанию, ни по схеме ничего не понятно

[Dimka]

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

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

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

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

[LightSin]

помойму делал что то похожее, для каждого клиента создавался поток, средствами 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);

[RXL]

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

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