2

このパターンは、このスレッドセーフでない環境でスレッドロックを実現するために機能しているようです。

ただし、パターンとベストプラクティスの観点から（特に自分で理解したので）、同じ結果を照合する2つのコレクションを公開することに過度に怒っているわけではありません。ただし、安全でないコレクションは公開する必要があり、プライベートにして「AddResult（x）」メソッドを使用したくありません。

これはこの問題を解決する正しい方法ですか？

public class UnsafeObject
{
    public ObservableCollection<HighSpeedObject> ResultsUnsafe { get; set; }

    /// Accessed by UI thread once every 100ms
    public List<HighSpeedObject> Results
    {
        get
        {
            lock (_padlock)
            {
                return ResultsUnsafe.ToList();
            }
        }
    }

    private readonly static object _padlock = new object();
}
4

1 に答える 1

3

ObservableCollectionz<T>クラスのインスタンスはスレッドセーフではないため、ソリューションは安定していません。

プロパティのロックは、Results一度に1つのスレッドがそのプロパティを使用できることを保証するだけですが、プロパティを保護するものではありませんResultsUnsafe。他のスレッドは、プロパティがリストを作成しているときに、ResultsUnsafeプロパティのコレクションを変更できます。Results

補足：非静的データのロックの識別子として静的メンバーを使用しています。つまり、ロックにより、保護するデータがあるインスタンスだけでなく、クラスのすべてのインスタンスでアクセスが防止されます。静的データを保護するには、静的メンバーを識別子として使用する必要があります。インスタンスデータを保護するには、インスタンスメンバーを識別子として使用する必要があります。

于 2013-02-17T22:07:29.820 に答える