Silverlight Threading и его использование

Question

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

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

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

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

Спасибо за помощь

Answer 1

Tomasz Janczuk также указал , что, если поток пользовательского интерфейса довольно занят, вы можете значительно улучшить производительность даже асинхронных вызовов WCF, направляя их в отдельный поток. И я должен отметить, что поток пользовательского интерфейса может быть ужасно занят тем, что вы не ожидаете, что он будет переживать циклы, такие как вычисление теней и тому подобное, поэтому это может стоить исследовать (и измерить) для вашего приложения. 1003 *

Тем не менее, я писал LOB-приложения большую часть двух десятилетий, и кроме синхронного ввода-вывода, я не нашел много сценариев, в которых добавление нескольких потоков в LOB-приложение стоило бы дополнительной сложности.

Редактировать 04.02.10: на днях я пообедал с Томашем Янчуком и некоторыми другими людьми из команды WCF, и они разъяснили мне несколько вопросов о том, как WCF работает с фоновыми потоками Silverlight. Есть две вещи, которые нужно учитывать: отправка данных и их получение (скажем, от дуплексных обратных вызовов или завершений асинхронных вызовов). Когда вы отправляете данные, вызов всегда будет выполняться из потока, который на самом деле делает вызов. Поэтому, если у вас много данных, которые необходимо сериализовать, вы можете получить небольшое повышение производительности, перенаправив исходящий вызов в фоновый поток (скажем, с помощью ThreadPool.QueueUserWorkItem). Но вряд ли это будет существенное повышение производительности.

Однако, когда вы получаете данные либо через дуплексный обратный вызов, либо через асинхронный метод xxxCompleted, данные всегда принимаются в потоке, в котором первоначально было открыто соединение. Это означает, что если вы открываете соединение явно, оно получит данные в этом потоке; но если вы неявно открываете соединение, оно получит данные о потоке, в котором вы установили свое первое исходящее соединение. Это не будет иметь большого значения, если вам нужно будет обновлять пользовательский интерфейс при каждом обратном вызове, поскольку вам нужно будет просто перенаправить обратный вызов в поток пользовательского интерфейса. Но если есть моменты, когда вам просто нужно сохранить данные для будущей ссылки или обработки, вы можете значительно повысить производительность, открыв соединение в отдельном потоке, чтобы вы могли получать и обрабатывать обратные вызовы, не ожидая в потоке пользовательского интерфейса .

Надеюсь, это поможет. Думал, что я запишу это, пока у меня все еще свежо в голове.

Answer 2

Для Silverlight применяются те же преимущества, что и для других приложений. Если вы выполняете длительные вычисления на клиенте и не хотите связывать основной / пользовательский поток, тогда выбор потоков является очевидным выбором.

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