Most objects do not have affinity to the thread in which they were created. Some objects in the System.Windows.Forms
namespace (i.e. Winforms) and in, or related to, the System.Windows.Controls
namespace (i.e. WPF) do, for very particular reasons having to do with how those objects interact with the native Windows APIs. This sort of thread affinity is found in a number of other APIs, especially those related to GUIs.
But those are all special cases. Any type for which you want to track what thread was used to create it, that type will have to implement that behavior explicitly (as you see in the Winforms objects). The List<T>
class has no reason to be tied to a specific thread, and thus that type has nothing in it that would track which thread was used to create it.
If you want a list type that tracks what thread was used to create it, you'll have to create your own. You can, of course, inherit List<T>
for that purpose. For example:
class ThreadList<T> : List<T>
{
public int ThreadId { get; } = Thread.CurrentThread.ManagedThreadId;
// add your constructors here...
}
But the fact is, your question very much seems like an XY Problem question. That is, you only think you need to know the thread that was used to create the object. For the objects that don't track the thread which created them, there is no such thing as the "owner thread". Once the object is created, it's free to be used with any thread that needs it.
It's not clear from your question why it is you think you need to know the thread that created the object. Possibly you're under the misimpression that the object would behave differently in the hypothetical "owner thread" than in other threads, or maybe you think there's some type of thread-safety that can come from using the object in the "correct" thread (or lack of thread-safety from using in the "wrong" thread). Or maybe it's something completely different.
You will probably be better served if you can ask a different question, in which you explain why you think you need this information and what specifically you intend to do with it.
Additional reading:
Why are some objects not accessible from different threads?
Invoking method on thread which created object
Per-thread memory management in C#
Is there one managed heap per CLR or per process?
The first two links discuss those scenarios where objects are tied to specific threads. They may help you understand those scenarios better, as well as understand why that thread-affinity doesn't apply to all objects.
The last two above discuss a possible approach that might address whatever it is you're looking to find. That is, while you can't in code get this information readily, if you enable server-mode garbage collection on some platforms, you may find objects allocated in different heaps depending on which thread allocated the object, and this information might show up in a memory profiling scenario.