Здравствуйте, d8m1k, Вы писали:

В этом случае меня очень сильно смущает ConcurrencyMode.Single

Single

The service instance is single-threaded and does not accept reentrant calls. If the InstanceContextMode property is Single, and additional messages arrive while the instance services a call, these messages must wait until the service is available or until the messages time out.

D>Клиет находится тут, сервер вот он:
D>

D>[ServiceContract]
D>public interface IThread {
D>    [OperationContract]
D>    void Start(int nTasks, int nActions);

D>    [OperationContract]
D>    byte[] Status();
        
D>    [OperationContract]
D>    int StatusSimple();
D>}
D>

Потом, я очень надеюсь, что IThread — это всего лишь пример, а не реальный код, поскольку текущий пример никак не вяжется с моим видением дизайна вообще и SOA, в частности. Так, меня смущают имена (они ничего не говорят о том, что они делают), меня смущают типы (почему Status возвращает массив байт?, почему StatusSimple — это int)? Если это все в качестве тестов, то ОК, если из этого "прототипа" что-то переедет в продакшн, то это не хорошо.

К тому же, сюда очень классно ложится идея реактивного программирования

Автор: Тепляков Сергей Владимирович
Дата: 06.02.11

вообще, и упомянутых callback интерфейсов в частности.

В результате, я бы дизайнил сервис таким образом: есть метод сервиса:

[c#]
[ServiceContract(CallbackContract = typeof(ICustomServiceCallback)]
public interface ICustomService
{
// Метод должен называться так, чтобы было понятно, что он делает.
// вообще говоря, taskCount и actionsCount — это деталь реализации сервиса и должна
// управляться именно им. Ведь именно при деплоя сервиса будет известно, какое
// количество одновременных задач является максимально эффективным с точки зрения эффективности
// Метод возвращает некий session id, который мы потом будет передавать в callback-и,
// чтобы клиент понял, для какого запроса приходят данные
string StartProcessing();
}

public interface ICustomServiceCallback
{
// Через этот метод мы будем уведомлять клиента о том, что операция исполняется
// и мы уже получили некоторые результаты
void Progress(string correlationId, CustomType[] processedData);
}
[c#]

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

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