同步集合< T>建议 [英] Synchronized Collection<T> Recommendation
问题描述
实现从Collection< T>继承的同步
（线程安全）类的推荐模式是什么？例如，我想要
来实现[类型为
System.Threading.ReaderWriterLock]的SyncRoot属性。我确实看到我可以覆盖
（受保护）方法InsertItem，RemoveItem，ClearItems和SetItem。
但是，我没有看到GetItem的覆盖。 />
最基本的问候，
Michael
What is the recommended pattern for implementing a synchronized
(thread-safe) class that inherits from Collection<T>? For example, I want
to implement a SyncRoot property [of type
System.Threading.ReaderWriterLock]. I do see where I can override
(protected) the methods InsertItem, RemoveItem, ClearItems, and SetItem.
However, I do not see an override for GetItem.
Kindest regards,
Michael
推荐答案
On Sun，2006年4月30日09 ：45：40 -0500，Michael Primeaux
< mj ******** @ msn.com>写道：
On Sun, 30 Apr 2006 09:45:40 -0500, "Michael Primeaux"
<mj********@msn.com> wrote:
实现从Collection< T>继承的同步
（线程安全）类的推荐模式是什么？例如，我希望
实现[类型为
System.Threading.ReaderWriterLock]的SyncRoot属性。我确实看到我可以覆盖
（受保护）方法InsertItem，RemoveItem，ClearItems和SetItem。
但是，我没有看到GetItem的覆盖。
最基本的问候，
Michael
What is the recommended pattern for implementing a synchronized
(thread-safe) class that inherits from Collection<T>? For example, I want
to implement a SyncRoot property [of type
System.Threading.ReaderWriterLock]. I do see where I can override
(protected) the methods InsertItem, RemoveItem, ClearItems, and SetItem.
However, I do not see an override for GetItem.
Kindest regards,
Michael
您可以继承ICollection< T>并写一个同步的包装器，
可以接受任何ICollection< T>并使所有方法同步。然后
你可以写一个标准的非同步集合并将它包装成同步的
一个吗？
一件事你不能从某种程度上说，某些方法如
FastAdd（T []数组）并没有被添加而不是调用SetItem
直接调用底层数据存储区速度。现在你有一个
未同步的方法。使用包装器时，由于FastAdd方法将被隐藏，因此不会发生这种情况。如果你想使用你的
必须明确地添加对它的访问权限并且可以再次确保它被同步。
Infact Collection< T>只是IList< T>的包装器所以你可以写一个IList< T>同步IList< T>的包装器。然后将这个
同步列表传递给Collection< T>：
List< T> baseList = new List< T>（）;
SyncronizedList< T> syncedList = new SyncronizedList< T>（baseList）;
Collection< T> col = new Collection< T>（syncedList）;
不幸的是，他们似乎已经从ICOLlection< T>中删除了来自
的IsSyncronized属性。接口，所以没有办法判断一个通用的
集合是否已经同步，所以你只需将它包装起来就好了。
不是。这是一种耻辱，因为它意味着Collection< T> .IsSyncronized
总是返回false，即使内部列表实际上是同步的。
You could inherit from ICollection<T> and write a synced wrapper that
can accept any ICollection<T> and make all the methods syncronized. Then
you can write a standard non synced collection and wrap it in a synced
one?
For one thing you cannot garuntee that at some point some method such as
FastAdd(T[] array) doesn''t get added that instead of calling SetItem
calls directly into the underling datastore for speed. Now you have an
unsyncronized method. With a wrapper this wouldn''t happen due to the
fact that the FastAdd method would be hidden. If you wanted to use you''d
have to explicitly add access to it and can again ensure it is synced.
Infact Collection<T> is just a wrapper for IList<T> so you could write
an IList<T> wrapper that syncronizes an IList<T> then pass this
syncronized list into Collection<T>:
List<T> baseList = new List<T>();
SyncronizedList<T> syncedList = new SyncronizedList<T>(baseList);
Collection<T> col = new Collection<T>(syncedList);
Unfortunatly they seem to have dropped the IsSyncronized property from
the ICollection<T> interface, so there is no way to tell if a generic
collection is already syncronized so that you only have to wrap it if it
isn''t. This is a shame as it means that Collection<T>.IsSyncronized
always returns false even if the inner list is infact syncronized.
Chris 。感谢您的回复。我读过许多关于为什么的博客和文章。
微软没有 - 我引用 - 犯了同样的错误关于在
..NET 2.0框架中包含SyncRoot和IsSynchronized属性，他们在.NET中做了
1.1。
$ b $恕我直言，我不同意微软的推理：
http://blogs.msdn.com/brada/archive/.../28/50391.aspx 并确实
用于SyncRoot和多操作中的IsSynchronized属性
场景（即添加一个项目并在同一个受保护的
操作中删除另一个项目）。
除非我遗漏了某些内容，否则似乎不允许在Collection< T>上覆盖
项目检索是一种疏忽。当然我可以使用
" new" Collection< T>上的关键字索引器，但这看起来并不优雅。
再次，感谢您的回复。
- m
" Chris Chilvers" <柯**** @ dynafus.com>在消息中写道
新闻：ea ******************************** @ 4ax.com ...
Chris. Thanks for your reply. I''ve read many blogs and articles on "why"
Microsoft didn''t--and I quote--"make the same mistake" as they did in .NET
1.1 regarding inclusion of the SyncRoot and IsSynchronized properties in the
..NET 2.0 framework.
IMHO, I disagree with Microsoft''s reasoning:
http://blogs.msdn.com/brada/archive/.../28/50391.aspx and do certainly
find use for the SyncRoot and IsSynchronized properties in multi-operation
scenarios (i.e. add one item and remove another in the same protected
operation).
Unless I''m missing something, it seems as though not allowing override of
item retrieval on Collection<T> is an oversight. Granted I could use the
"new" keyword on the Collection<T> indexer but that doesn''t seem as elegant.
Again, I appreciate your reply.
- m
"Chris Chilvers" <ke****@dynafus.com> wrote in message
news:ea********************************@4ax.com...
On Sun，2006年4月30日09:45:40 -0500，Michael Primeaux
< mj ******** @ msn.com>写道：
On Sun, 30 Apr 2006 09:45:40 -0500, "Michael Primeaux"
<mj********@msn.com> wrote:
实现从Collection< T>继承的同步
（线程安全）类的推荐模式是什么？例如，我希望
实现[类型为
System.Threading.ReaderWriterLock]的SyncRoot属性。我确实看到我可以覆盖
（受保护）方法InsertItem，RemoveItem，ClearItems和SetItem。
但是，我没有看到GetItem的覆盖。
最基本的问候，
迈克尔
What is the recommended pattern for implementing a synchronized
(thread-safe) class that inherits from Collection<T>? For example, I want
to implement a SyncRoot property [of type
System.Threading.ReaderWriterLock]. I do see where I can override
(protected) the methods InsertItem, RemoveItem, ClearItems, and SetItem.
However, I do not see an override for GetItem.
Kindest regards,
Michael
你可以继承ICollection< T>并编写一个同步的包装器，
可以接受任何ICollection< T>并使所有方法同步。那么你可以写一个标准的非同步集合并将它包装成同步的一个吗？
一方面你不能在某种程度上指望某些方法如
FastAdd（T []数组）并没有被添加，而是直接调用SetItem
调用到底层数据存储区以获得速度。现在你有了一个未经同步的方法。使用包装器时，由于FastAdd方法将被隐藏，因此不会发生这种情况。如果你想使用，你必须明确地添加对它的访问权限，并且可以再次确保它被同步。
Infact Collection< T>只是IList< T>的包装器所以你可以写一个IList< T>同步IList< T>的包装器。然后将这个
同步列表传递给Collection< T>：
List< T> baseList = new List< T>（）;
SyncronizedList< T> syncedList = new SyncronizedList< T>（baseList）;
Collection< T> col = new Collection< T>（syncedList）;
不幸的是，他们似乎已经从ICollection< T>中删除了IsSyncronized属性。接口，所以没有办法判断一个通用的
集合是否已经同步，所以如果它不是，你只需要包装它。这是一种耻辱，因为它意味着Collection< T> .IsSyncronized
总是返回false，即使内部列表实际上是同步的。
You could inherit from ICollection<T> and write a synced wrapper that
can accept any ICollection<T> and make all the methods syncronized. Then
you can write a standard non synced collection and wrap it in a synced
one?
For one thing you cannot garuntee that at some point some method such as
FastAdd(T[] array) doesn''t get added that instead of calling SetItem
calls directly into the underling datastore for speed. Now you have an
unsyncronized method. With a wrapper this wouldn''t happen due to the
fact that the FastAdd method would be hidden. If you wanted to use you''d
have to explicitly add access to it and can again ensure it is synced.
Infact Collection<T> is just a wrapper for IList<T> so you could write
an IList<T> wrapper that syncronizes an IList<T> then pass this
syncronized list into Collection<T>:
List<T> baseList = new List<T>();
SyncronizedList<T> syncedList = new SyncronizedList<T>(baseList);
Collection<T> col = new Collection<T>(syncedList);
Unfortunatly they seem to have dropped the IsSyncronized property from
the ICollection<T> interface, so there is no way to tell if a generic
collection is already syncronized so that you only have to wrap it if it
isn''t. This is a shame as it means that Collection<T>.IsSyncronized
always returns false even if the inner list is infact syncronized.
|恕我直言，我不同意微软的推理：
| http://blogs.msdn.com/ brada / archive /.../ 28 / 50391.aspx 并确实
|在多操作中查找用于SyncRoot和IsSynchronized属性
|场景（即添加一个项目并在同一个受保护的
我必须同意MS这个。要添加一个项目并删除相同的
保护操作意味着您将锁定3次。一次为
锁定（SyncRoot），并在内部为每个方法执行一次。如果你在
中添加一个.Count，那么就有四个锁。没错，你已经拥有了锁，所以其他的
锁操作速度更快，但仍然浪费了开销。作为该系列的用户，它通常更干净，更快，只需使用您自己的锁和自己同步访问该系列。另外，你可能需要利用那个
锁来解决其他问题。
-
William Stacey [MVP ]
| IMHO, I disagree with Microsoft''s reasoning:
| http://blogs.msdn.com/brada/archive/.../28/50391.aspx and do certainly
| find use for the SyncRoot and IsSynchronized properties in multi-operation
| scenarios (i.e. add one item and remove another in the same protected
| operation).
I have to agree with MS on this one. To add an item and remove in the same
protected operation means your taking the lock 3 times. Once for the
lock(SyncRoot), and once for each method internally. If you add a .Count in
there, then its four locks. True, you already own the lock, so the other
lock operations are faster, but it is still wasted overhead. As a user of
the collection, it often cleaner, and faster, to just use your own lock and
sync access to the collection yourself. Plus you may need to leverage that
lock for other issues outside of the collection.
--
William Stacey [MVP]
这篇关于同步集合< T>建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
