Hello,
the well respected german computer magazine
c't reports in an
article
of its release 26/03
on page 214, that the .Net multithreading
support
currently suffers from several strangeness
factors.
The class ThreadPool suffers from several
anomalies:
The thread pool of a process is limited by 25
threads per processor.
GetMaxThreads() and GetAvailableThreads() deliver
the values 25/25
with .Net 1.0 and
25/1000 with .Net 1.1.
The new
threads obey to a pretty ackward activation pattern, new
threads are started with individual offsets of
500ms to each other!
The garbage collector starts after one minute
after the demise of a
thread. If new threads are requested in
between, one again suffers
the 500ms penalties from above.
Further experiments trying to start all
required threads in advance
suffered from being queued automatically from
thread 25 on, so
this didn't help so much either.
Running one thread under full load, makes
the system take up to
5 seconds to start another thread.
Attempts to work without ThreadPool suffered
also from several
anomalies and could even crash the .Net
executive:
The executive is quiet sensitive when one
tries to Resume() an
already running process etc, which might mean some
extra
private bookkeeping.
Attempts with subclassing BaseThread worked but
occasionally
resulted in a termination with return code 0 with .Net 1.0 and a
reported stack overflow with .Net 1.1.
Closing a window while one owns
homemade background thread
is running creates a
zombie thread.
Altogether the authors hope, that further releases
of .Net like
.Net 2.0 will help to improve the
situation.
Regards,
Martin