1

現在、マルチスレッド WP 7.1.1 アプリケーションで作業しており、「初期段階」で例外をスローせずにアプリケーションが終了する時間の半分強をわずかに上回っています。これは、すべてのスレッドが 0x0 を返し、Closing/Exit/Quit イベントを入力せずに単純に終了します。

...
The thread '<No Name>' (0xfde00d2) has exited with code 0 (0x0).
The thread '<No Name>' (0xe860116) has exited with code 0 (0x0).
The thread '<No Name>' (0xfdf00c6) has exited with code 0 (0x0).
The thread '<No Name>' (0xf8d012e) has exited with code 0 (0x0).
The thread '<No Name>' (0xfd5010e) has exited with code 0 (0x0).
The thread '<No Name>' (0xfbc011a) has exited with code 0 (0x0).
The thread '<No Name>' (0xf9900ee) has exited with code 0 (0x0).
The program '[268042506] UI Task: Managed' has exited with code 0 (0x0).
EOL

「初期段階」とは正確にはどういう意味ですか? 「Windows Phone パフォーマンス分析」を使用してアプリのプロファイリングを行い、いくつかのデバッグ メッセージといくつかのログを合わせて、開始後約 3 ～ 4 秒と推定しました。彼の時点で、GUI はすでに非常に短い時間しか表示されていません。

次の呼び出しが原因で問題が発生することはほぼ確実です。

private static List<MyEntries> EntriesLoad()
{
    using(var context = Context.ReadOnly) // <- works
    {
        return context.MyEntries.Where(m => !m.Deleted).OrderBy(m => m.Name).ToList(); // <- problem
    }
}

private async void EntriesReload()
{
    EntriesLoaded = false; // <- called
    var entries = await TaskEx.Run<List<MyEntries>>(EntriesLoad); // <- called
    EntriesLoaded = true; // <- only get's called 50% of the time/ otherwise app quits
}

DataContext でのマルチスレッドの問題を防ぐために、呼び出しごとに新しいコンテキストが作成されます。

public static Context ReadOnly 
{
    get { return new Context(ConnectionReadOnly); }
}

Async CTP 3 の代わりに BackgroundWorker と ThreadPool を試してみましたが、同じ効果がありました。非常によく似た質問が以前に何度も出されたことは知っていますが、私の問題に対する解決策はまだ見つかりませんでした。例外の原因となっている正確なメソッド (理由、場所) を見つける方法/プログラムはありますか? 作成できるスレッドの数に制限はありますか? この方法で DataContext を安全に使用できますか?

あなたの助けに感謝します。

4

2 に答える 2

2

メソッドが例外をスローするasync voidと、その例外は「コンテキスト」 (この場合は UI コンテキスト) にそのまま渡されます。

したがってEntriesReload、try/を呼び出していても、catchによって発生した例外をキャッチすることはありませんEntriesReload。

asyncメソッドは、返す必要がない限り (イベント ハンドラなど)、常にorを返す必要がTaskあります。Task<TResult>voidasync

次に、 を呼び出すEntriesReloadとawait、結果が返されます。これでクラッシュは修正されませんが、例外が表示されます。

于 2012-05-31T11:09:23.313 に答える
0

スティーブンさん、返信ありがとうございます。提案された変更ではまだ例外を見つけることができませんでしたが、あなたの答えは、カーテンの後ろで何が起こっているのかをよりよく理解するのに役立ちました. それでは、またよろしくお願いいたします。

私は最終的に、アプリケーションが (ほぼ半分の時間で) 起動直後にランダムに終了する原因となったすべての「サイレント」例外を取り除くことができました。驚いたことに、それはおそらく私のコードが原因ではなく、DataContext クラスで発生した可能性があります。どうして？私のアプリケーションでは、2 つの異なる接続文字列を使用しています。

/* with DeferredLoadingEnabled = false; ObjectTrackingEnabled = true; */
private const string Connection = "Data Source=isostore:/MyDatabase.sdf;max buffer size=1024;max database size=512;";

/* with DeferredLoadingEnabled = false; ObjectTrackingEnabled = false; */
private const string ConnectionReadOnly = Connection + "File Mode = read only;";

例外は、ReadOnly 接続文字列を使用する DataContext での読み取り操作中にのみ発生しました (戻り値の割り当て後、前、または割り当て中ではありません)。ReadOnly プロパティを取り除き、他のコード行を 1 行も変更しないことで、私の問題は完全に解決されました。では、DataContext またはライブラリの 1 つにスレッドの問題があるのでしょうか? ReadOnly 接続を使用しないことによるパフォーマンスへの影響を実際に判断することはできませんが、取得するデータは少量であり、DataContext を非常にアトミックな方法で使用しているため、オーバーヘッドが発生する可能性は気にしません。特定の使用例。

于 2012-06-07T14:41:56.233 に答える