In this book I read that each instance of the Thread
class is actually allocating a kernel object - and this is one of the overheads of using Thread
Thread is a managed object first, you know the System.Threading.Thread class. It is an internal CLR object next, a C++ class also named Thread. There's rather a massive amount of plumbing involved with it, iceberg style. That plumbing certainly uses kernel objects, five of them. Something you can see in Taskmgr.exe. One of them is the native operating system thread handle, the other four are a bit mysterious but probably are synchronization object handles.
The decoupling of Thread with actual Windows thread objects in .NET 2.0 is pretty infamous. It is only technically possible, nobody well known actually ever implemented a CLR host that made it work. It was an important project for the SQL Server team to implement Thread with fibers and they gave up on it. Couldn't make it reliable enough. Hasn't been tried since that I know of.