Re: Synchronized Collection<T> Recommendation

Regarding the Thead A, B, A scenario below, ultimately it's the
responsibility of the developer to ensure Thead A holds a lock until its
operations are complete. I mean, that's multi-threaded programming 101. I
can see an argument that assumes I hold a reference to an object (contained
in a collection) and that I set that reference equal to a new object
instance without first aquiring ownership of a synchronization primitive.
Effectively, I just updated the collection but without first aquiring a
lock. Again, you can't protect the developer from everything but then again
the developer had better know what they're doing. Ironically, this is the
very scenario that having a SyncRoot property addresses.

The intent of my original email was to inquire as to the recommended
solution for implementing a thread-safe collection that inherits from
Collection<T>. I certainly understand why the IsSynchronized property always
returns false and the SyncRoot property returns the current instance. I do
agree with this approach as the earnest is on the consumer to ensure
"proper" locking. I'm really just curious as to why no overridable members
exist for item retrieval on the Collection<T> class.

"Chris Chilvers" <keeper@xxxxxxxxxxx> wrote in message
news:ek1a52pd78ni0oe6mmic352smoskcvtmfm@xxxxxxxxxx
All this locking will however slow things down for such things as
for (int i = 0; i < list.Count; i++) ...

Which will now lock every time it reads something, and what if:

Thread A increments i to the last element (count-1)
Thread B deletes the last element
Thread A tries to read the last element

In these cases I'd favor having an unsyschronized collection and having
some specified way to obtain the collection exclusivly.

It just seems to me that syncronization on such things as a collection
are very much dependent upon what the collection is storing and what the
data is being used for. Without knowing the specific case it will be
used it just seems like one cannot reliably choose the locking mechanism
or guarantee that it will even work correctly as shown in the previous
example.


.

Relevant Pages

  • Re: sched_yield() options
    ... I'm working with a developer on one application that looks ... and it has to lock whole pools. ... blocking on those mutexes. ... You are assuming that random latencies are necessarily bad. ...
    (Linux-Kernel)
  • Re: sched_yield() options
    ... I'm working with a developer on one application that looks ... and it has to lock whole pools. ... latencies may be significantly better than predictable high latency. ... in the case I'm looking at there are two threads running with one message queue in the center. ...
    (Linux-Kernel)
  • 2.0 Collections data
    ... I suppose the answer would be yes as the 2.0 collections are type safe and ... data collection (protected by a lock based on the SyncRoot property of the ... from collection is also protected by a lock on SyncRoot property). ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: 2.0 Collections data
    ... This can be the Monitor class or a Mutex, ... In your case, if possible, you should only exclusively lock when you are ... data collection (protected by a lock based on the SyncRoot property of the ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: UPDATE LOCK only with locking hint?
    ... > lock on the primary key index of a table - index is clustered so I assume> the index is the table - and a second process also holds an update lock on ... > I understood that two update locks are not compatible, so I looked up the> error log fragment which I parsed and here it is: ... this lock is compatible with an> update lock. ... I did find a procedures> that uses a cursor to delete from depending tables (I guess the original> developer never heard of cascading delete) before deleting the "parent"> record, could this be causing the upate lock? ...
    (microsoft.public.sqlserver.server)
Loading