System.Collection.Generic.Queue - Where did SyncRoot go?

[=?Utf-8?B?TWluIFlvbmc=?=]

I'm not sure if I've just lost it but, I no longer see the property SyncRoot
on a Queue. I see that it's a member of the ICollection Base Object, but it's
not exposed.

Was this intended? Besides writing a wrapper class for Queue, what is the
intended way to lock the queue to enforce proper synchronization ?

using System;
using System.Collecti ons.Generic;
using System.Text;

namespace DummyApp
{
class DummyApp
{
static void Main(string[] args)
{
Queue<intiq = new Queue<int>();

lock(q.SyncRoot )
{
DoSomething();
}
}
}
}

This is the error I would get when compiling

'System.Collect ions.Generic.Qu eue<int>' does not contain a definition for
'SyncRoot'

[Marc Gravell]

Re: System.Collecti on.Generic.Queu e - Where did SyncRoot go?

I believe the view taken was that in most cases the SyncRoot approach
simply wasn't worth it; and synchronising *inside* the object (for
most collections) is worse, as it only protects individual objects -
not longer atomic operations. Note that if you cast to ICollection,
the SyncRoot is still there, and looking at reflector it will allocate
a new sync object when first requested (even though it reports
IsSynchronized as false).

However; you only need to worry about the SyncRoot if you are
threading... and if you are threading you have enough complexity
already... I would tend to encapsulate the Queue<Tinto a class that
describes what I am trying to do, rather than how I am implementing
it; since I recognise that this class is threaded, I can make it
thread-safe with a private lock inside the object, as well as
encapsulating other features such as Monitor.Wait (if reading empty)
and Monitor.Pulse (if writing first entry) - assuming of course that
this is a work queue (which it sounds like).

Marc

[Marc Gravell]

Re: System.Collecti on.Generic.Queu e - Where did SyncRoot go?

only protects individual objects -

not longer atomic operations.

I meant "individual method calls"