1

Sculptureソフトウェアパッケージを使用して生成されたアプリケーションがあります。つまり、プロジェクトはPrismアプリケーションのコードとほぼ同等です。

モデルの一部は、すべてのWCFサービス呼び出しが同期的に実行されることですが、バックグラウンドスレッドで実行されます（実際には非同期呼び出しでもありますが、Sculptureバックグラウンドスレッドメソッドは、後続のコードを実行する前に応答を待機します）。

アプリケーションをデプロイしたところ、テストしたすべてのマシンの約50％が最初のサービスコールを通過しないことがわかりました。デバッグとリリースの両方のSilverlightランタイムと、動作するマシンと失敗するマシン上のWindows 7の両方が混在しているため、失敗するマシンにはパターンが表示されません。別のブラウザでも同じように失敗するため、マシン固有です。唯一の手がかりは、それらがすべて古いPCのように見えることです。

アイデアは誰ですか？

4

1 に答える 1

1

原因が見つかりました。生成されたサービス コールにスクールボーイ エラーがあります。

この写真の何が問題になっていますか?:

while (true == userState.IsBusy)
{}

true ==（C＃では必要ありません）の古い学校の使用を無視すると、基本的に、一部のマシンwhileではループが非常にきつくロックされ、IsBusy状態が設定されることはありません。また、サービス呼び出しが行われるたびに、アプリケーションが常に 100% のプロセッサ使用率で実行されていることも意味します。

すべてのサービス呼び出し while ループに Thread.Sleep(100) を追加することで問題を修正しました。例えば：

while (userState.IsBusy)
{ 
    Thread.Sleep(100);
}

私たちのアプリは現在、Silverlight 対応のすべてのマシンで (当然のことながら) 動作しており、起動に使用するプロセッサが大幅に削減されています。

公平を期すために、私たちは最新リリースの彫刻を使用していませんが、商用パッケージにこのようなばかげた間違いが見られるのは非常に驚くべきことです.

于 2010-10-06T09:58:49.553 に答える