Given: Constructing an ADO Connection object from one thread and giving it to another thread is forbidden. The two threads are different apartments, and even though the first thread will never touch it again (not even maintain a reference to it!), it doesn't matter.
That ADO Connection object was created by ThreadA, ThreadA is the only thread, ever, under any circumstances, at all, ever, that is allowed to use that Connection object, ever.
Now replace "ADO Connection" with "ADO.NET Connection". Does the same rule apply?
i know that most objects in the .NET framework are not thread-safe. For example, the DictionaryEntry structure in the SDK says:
Thread Safety
Any public static members of this type are thread safe. Any instance members are not guaranteed to be thread safe.
i understand that not thread-safe means that i have to synchronize access to the object if i am going to access it from different threads. That's all well and good, and i could ensure only one thread access the object at a time:
lock (myObject)
{
...
}
But there's something more than not being thread-safe.
In COM, (some) objects are bound to the "apartment" that created it. Once the object has been constructed on one apartment, you are forbidden from accessing it from another apartment - no matter how much you protect that object from multiple simultaneous thread access.
Does a similar concept exist in .NET?
More Information
i know you are forbidden from accessing Controls from threads other than the one that created it - even if you use it in a thread-safe manner. This is not documented on MSDN:
Thread Safety
Only the following members are thread safe: BeginInvoke, EndInvoke, Invoke, InvokeRequired, and CreateGraphics if the handle for the control has already been created. Calling CreateGraphics before the control's handle has been created on a background thread can cause illegal cross thread calls.
There is no mention of Controls throwing exceptions when you create and use them from a single thread - when that thread is not the first thread that was created when the application started.
But what about arbitrary objects? What about:
public class MyClass
{
int _number;
public int Number { get { return _number; } set { _number = value; } }
}
MyClass myObject = new MyClass();
As long as i synchronize access to myObject two threads are allowed to talk to it?
The same goes for:
List<Object> sharedList = new List<Object>();
Two threads can talk to the list, as long as they don't do it simultaneously, usually with:
lock (sharedList)
{
sharedList.Add(data);
}
are two threads allowed to touch the same object?
The same goes for:
IAsyncResult ar = BeginSetLabelToTheValueINeed(label1);
...
EndSetLabelToTheValueINeed(ar);
The same goes for:
//Fetch image on connection that is an existing DB transaction
public static Bitmap GetImageThumbnail(DbConnection conn, int imageID)
{
}
being converted into the asynchronous delegate pattern:
//Begin fetching an image on connection that is an existing DB transaction
IAsyncResult ar = BeginGetImageThumbnuts(conn, imageID, callback, stateOjbect);
...
//Finish fetching an image on connection that is an existing DB transaction
Bitmap thumb = EndGetImageNumbthail(ar);
Rather than answering the question, people went off on a discussion about design patterns in ADO.NET. Please answer the question. Ignore the examples if they confuse and distract your squirrel brains.