1

I'm reading C# in a nutshell 4.0 - great reading! The best I ever had on .NET framework.

I've just finished Chapters 21/22/23, I thought I knew something about threading, but I seems I don't :) I was suprissed when reading about AMP (Asynchronous Method Pattern) and how it enables thread economy, and its comparsion to ordinary thread usage.

Bottom line:

I always thought that if I had a thread, and when that thread is doing something and then is waiting for condition (like Monitor.Pulse), all the stack information used by that thread is freezed. While waiting for that particular condition, thread can be reused to serve another task. So basically: 1 thread can execute multiple code paths at the same time. But obviously I was wrong. So my question is:

  • when tread starts, code it is executing is always the same (until code finishes and thread can be reused when talking about ThreadPool) ?
  • if so, when executing a long-running task, if I access ManagedThreadId property I will always get the same id?
John Saunders
  • 160,644
  • 26
  • 247
  • 397
dragonfly
  • 17,407
  • 30
  • 110
  • 219

2 Answers2

2

For both question: YES.

ThreadPool reuses threads that are not doing work, basically there is a daemon that cares about all the pool threads: if they are more than ThreadPool.MinThreads they will be deleted, otherwise they will be reused to do new work when ThreadPool.QueueWorkUserItem will be called.

So: until your work inside a thread hasn't finished it will not be deleted/reused also if you are using waiting mechanisms like Monitor.Wait / Monitor.Pulse :)

as-cii
  • 12,819
  • 4
  • 41
  • 43
2

The ManagedThreadId is constant during the execution of the thread. As written on MSDN

The value of the ManagedThreadId property does not vary over time, even if unmanaged code that hosts the common language runtime implements the thread as a fiber.

It's the ProcessThread.Id that can change. You can recover it through code like Getting the thread ID from a thread for example through AppDomain.GetCurrentThreadId

I'll add that what you thought COULD be true for threads executed as fibers. There was a plan for SQL Server to execute CLR "managed" code using fibers (SQL Server did use fibers at that time). There were projects to make the CLR fiber-compliant. In the end I think this project was dropped, but there are still signs (like the ManagedThreadId that is "distinct" from the OS Thread Id) (last year I researched very much if it was possible to use fibers in C#. The response was no :-) )

A quote from Fibers and the CLR

The CLR tried to add support for fibers in Whidbey. This was done in response to SQL Server Yukon hosting the runtime in process, aka SQLCLR. Eventually, mostly due to schedule pressure and a long stress bug tail related to fiber-mode, we threw up our hands and declared it unsupported.

and

Perhaps the biggest thing we did to support fibers intrinsically in the runtime was to decouple the CLR thread object from the physical OS thread.

Community
  • 1
  • 1
xanatos
  • 109,618
  • 12
  • 197
  • 280
  • Cheers! By asking question about ManagedThreadId and is it constant, I ment if my code will always be using the same thread.I.e.if I have following code: Monitor.Wait(); /* waits very long */ PrintID(); Monitor.Wait(); /* waits very long */ PrintID() etc..., will printing method always print the same id i.e. will my code be executed by still the same thread. – dragonfly Oct 16 '11 at 13:27
  • @dragonfly Yes. But be aware that the callbacks of asynchronous methods are (often) executed on different threads than the thread that called the async method and that if you use ASP.NET, your thread could change in certain points: http://piers7.blogspot.com/2005/11/threadstatic-callcontext-and_02.html – xanatos Oct 16 '11 at 13:29