Клиент-серверное приложение: Callback

[B_N]

MaTBeu, а где WaitFor*** по этому семафору? OpenSemaphore это своего рода аналог CreateSemaphore.

[MaTBeu]

Говорю же не шарю ничего в WinAPI функциях... Если Вам не трудно. Напишите код для WaitFor*** по данному семафору.

[B_N]

MaTBeu, еще раз внимательно прочитал тему и вот какие вопросы возникли:
Почему для очереди Вы используете список, а не queue, скажем?
Вы уверены, что нужен "Обработчик"? В принципе, здесь достаточно было бы обойтись одной очередью "внутри" сервера.
Классическая схема многопоточного сервера (в общем смысле в том числе) состоит в создании для каждого клиента одного серверного потока. Как я понял, Вы хотите сделать всё в рамках одного процесса так, что потоки на сервере будут "получаться сами собой", и после получения задания вся обработка будет происходить в одном, "центральном" потоке. Исходя из этого попытаюсь предложить такую схему, посмотрите, подходит ли она, тогда можно будет перейти к конкретному коду.

1. Поток-"клиент" обращается к серверу с некой задачей, обращение выглядит как включение задания в очередь заданий сервера через публичный метод. Добавление задачи, коли оно происходит конкурентно, нужно включить в критическую секцию. В семафоре здесь особого смысла нет - более чем одному потоку доступ к очереди на запись давать нельзя. Каждое задание включает адрес, по которому нужно поместить результаты и объект ОС Event, который будет сигналиться после выполнения задачи и помещения результатов по указанному адресу. После добавления задания клиент-поток встаёт в ждущий режим по функции WaitForSingleObject - ждёт выставления сигнала об обработке своего "заказа", после этого выводит результат и, видимо, завершается.

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

[MaTBeu]

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

ПС:
По поводу обработчика. Я честно сам хотел его убрать, потому что он только тормозит систему. Но было уже поздно. А заказчику безразлично как его программа работает. Так что... для себя я бы сделал лучше.

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