I want to creat custom thread pool so I can start next thread when some
active thread from pool goes sleep or finishes its execution
The latter (finishes its execution) I understand (but the existing
thread pools already deal with this just fine), but not the former
(sleeps).
The OS does a very nice job of scheduling threads, allowing one to run
when another is sleeping. Furthermore, what are you going to do if a
thread sleeps, then while a new thread you've started continues
working, the original thread wakes back up? If it's okay for the
second thread to continue working while the original thread is now not
sleeping, why do you have to wait for the original thread to sleep in
the first place?
If you really need multiple threads to coordinate when they are
executing, the code to manage that needs to exist from within the
threads. The threads can use synchronization objects, like an
AutoResetEvent, to coordinate execution, setting another thread's event
just before waiting on its own.
As I said in a different thread recently, only the threads themselves
have sufficient knowledge to correctly manage when they are executing
and not executing. You'd just be asking for big trouble to try to
manage that state of the threads externally.
There are a number of reasons for this, but one of the biggest is that
that's what the Windows thread scheduler is _already doing_. Trying to
add your own layer on top of that is bound to create some sort of
conflict somewhere. At best, you'll kill your application's
performance, and at worst you could create all sorts of hard-to-debug
bugs.
- I can not
modify logic in threads which will be added to thread pool.
The usual way a thread pool works is that the threads always exist, and
the pull some sort of execution context from a queue (for example, a
delegate to be executed) as they complete previous execution contexts.
No need to modify the logic within the code being executed by the
thread pool, since all of the control logic is outside of that code.
Of course, as I mentioned, the built-in thread pools already handle
this behavior perfectly.
There has to be some way how to know that thread sleeps because Windows
switch execution to new thread when active thread fall asleep ...
The Windows thread scheduler operates at a much lower level.
Furthermore, it is inherently tied to the act of "sleeping". A thread
cannot sleep without the participation of the thread scheduler, so it's
trivial for the thread scheduler to detect this case and switch to a
different thread.
But this behavior is not really exposed in any useful way outside of
the thread scheduler.
- or this
is not possible to find out in C# ?
It's not really even possible in a practical way with the native Win32 API.
That said, I doubt you really need to do what you think you need to do.
I think it's likely that if you stepped back and concisely described
the higher-level goal you're trying to achieve, some advice could be
provided for implementing that higher-level goal without doing the sort
of thread manipulation you say you want to do.
Pete
