.NET Poor threading architecture?

[Guest]

When I see things in .NET 2.0 like obsoletion of suspend/resume because of
the public reason MS gives of they think people are using them
inappropriately.. use mutex, monitor and other synchronization objects
instead and oh by the way you shouldn't be using them as they can cause
deadlock and other major problems, screams bug or threading architecture
issue and lack of willingness or priority to correct. In reality those API's
are for controlling starting and stopping of threads like umm for example an
Operating system does (surely MS knows something about that ) (I think
they should leave these and fix this.)

Of course there is the other issue that since threads are interruptible due
to the gc they must re-acquire locks afterwards and thus could be re-ordered
and then threading becomes non-fair.

Given these and other issues I think MS should reconsider making WinFX the
primary OS API, it's starting to scare me about what else is under the covers
we haven't found yet.

 

[Kevin Spencer]

Gee, this looks awfully familiar. I could almost swear it's a duplicate Post
from one posted on another newsgroup...

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

A lifetime is made up of
Lots of short moments.

 

[Willy Denoyette [MVP]]

Suspend/Resume are made obsolete just because of this "the willingness to
correct". These API's are calling the Win32 counterparts which are:
- not designed to be used from user code [see MSDN - SuspendThread API <This
function is primarily designed for use by debuggers. It is not intended to
be used for thread synchronization>]
- considered dangerous when used inappropriately from a highly virtualized
environment like .NET.

The same goes for Thread.Abort, but unfortunately this one cannot be made
obsolete.
Granted, these services should never have been included in .NET, they are
design mistakes, but you can't build such complex system without making
mistakes.
As for your suggestion to make WinFX the primary OS API, don't forget that
WinFX is a user level OO API build on top of Win32 (on Windows), that's
exactly the role of the CLR and the FCL - present a OO level API to the user
that virtualizes the underlying OS services. What you are suggesting is to
move this to the system level and expect all applications to be rewritten
using some managed language, or worse, penalize the native applications by a
call through a reverse thunking layer, no thanks.

Willy.



| When I see things in .NET 2.0 like obsoletion of suspend/resume because of
| the public reason MS gives of they think people are using them
| inappropriately.. use mutex, monitor and other synchronization objects
| instead and oh by the way you shouldn't be using them as they can cause
| deadlock and other major problems, screams bug or threading architecture
| issue and lack of willingness or priority to correct. In reality those
API's
| are for controlling starting and stopping of threads like umm for example
an
| Operating system does (surely MS knows something about that ) (I think
| they should leave these and fix this.)
|
| Of course there is the other issue that since threads are interruptible
due
| to the gc they must re-acquire locks afterwards and thus could be
re-ordered
| and then threading becomes non-fair.
|
| Given these and other issues I think MS should reconsider making WinFX the
| primary OS API, it's starting to scare me about what else is under the
covers
| we haven't found yet.

 

[Guest]

Suspend/Resume are made obsolete just because of this "the willingness to

correct". These API's are calling the Win32 counterparts which are:
- not designed to be used from user code [see MSDN - SuspendThread API <This
function is primarily designed for use by debuggers. It is not intended to
be used for thread synchronization>]

You need to be able to control your threads in .NET for various reasons,
these API's are sometimes critical and the only means for a developer to
accomplish specific functionality. I think they should make them so suspend
would stop the thread at a safe point from .NET's perspective and leave the
rest of the safety to the developer.

As for your suggestion to make WinFX the primary OS API, don't forget that

Suspend/Resume are made obsolete just because of this "the willingness to
correct". These API's are calling the Win32 counterparts which are:
- not designed to be used from user code [see MSDN - SuspendThread API <This
function is primarily designed for use by debuggers. It is not intended to
be used for thread synchronization>]
- considered dangerous when used inappropriately from a highly virtualized
environment like .NET.

The same goes for Thread.Abort, but unfortunately this one cannot be made
obsolete.
Granted, these services should never have been included in .NET, they are
design mistakes, but you can't build such complex system without making
mistakes.
As for your suggestion to make WinFX the primary OS API, don't forget that
WinFX is a user level OO API build on top of Win32 (on Windows), that's
exactly the role of the CLR and the FCL - present a OO level API to the user
that virtualizes the underlying OS services. What you are suggesting is to
move this to the system level and expect all applications to be rewritten
using some managed language, or worse, penalize the native applications by a
call through a reverse thunking layer, no thanks.

Willy.



| When I see things in .NET 2.0 like obsoletion of suspend/resume because of
| the public reason MS gives of they think people are using them
| inappropriately.. use mutex, monitor and other synchronization objects
| instead and oh by the way you shouldn't be using them as they can cause
| deadlock and other major problems, screams bug or threading architecture
| issue and lack of willingness or priority to correct. In reality those
API's
| are for controlling starting and stopping of threads like umm for example
an
| Operating system does (surely MS knows something about that ) (I think
| they should leave these and fix this.)
|
| Of course there is the other issue that since threads are interruptible
due
| to the gc they must re-acquire locks afterwards and thus could be
re-ordered
| and then threading becomes non-fair.
|
| Given these and other issues I think MS should reconsider making WinFX the
| primary OS API, it's starting to scare me about what else is under the
covers
| we haven't found yet.

 

[Brian Gideon]

You need to be able to control your threads in .NET for various reasons,
these API's are sometimes critical and the only means for a developer to
accomplish specific functionality. I think they should make them so suspend
would stop the thread at a safe point from .NET's perspective and leave the
rest of the safety to the developer.

Can you give us an example of where these APIs might be useful?

 

[Guest]

Sure.

In this case imagine you have some third party code you need to run, but you
need to control when it runs, be able to pause it, and be able to cycle it to
running or not running state to avoid burdening the CPU too much. I need the
code to run for a short period of time and then stop and then run again,
thread priorities are not enough, because CPU usage still could take place at
an inapproriate time causing data backups on a network socket.

I can't use standard sync here as I don't control it, and again the same
goes for having some sort of "flag" to tell the thread to "oh by the way..
can you hang on a minute...", which of course the code may not check often
enough and could purposely or accidentally ignore. Having the thread
suspend/resume mechanism is much more reliability. I can then actually
enforce a duty cycle on this third party code and ensure it does not run/use
more CPU than I would like.

Barring these API's in this scenario I am stuck with the only viable
alternative to try is threading priorities, which could still let a
particular thread run and use more CPU than I would like.

Any type of attempt to implement Operating system like behviour with
arbitrary threads would require access to suspend resume functionality.
Supposedly MS is writing a secure OS with .NET (Do you want to bet they use
suspend/resume- ok not much of a bet since any OS kernel developer knows
those methods MUST be there).

 

[Andre Kaufmann]

[...]
You need to be able to control your threads in .NET for various reasons,
these API's are sometimes critical and the only means for a developer to
accomplish specific functionality. I think they should make them so suspend
would stop the thread at a safe point from .NET's perspective and leave the
rest of the safety to the developer.

IMHO Suspend is one of the most dangerous functions in the Win32 API
regarding deadlocks. There's no chance to safely call Suspend and even
the .NET runtime cannot ensure that suspending a thread will be always
safe.

Either the .NET runtime must wait till the thread releases all
synchronization objects currently held -> but what if the thread won't
release them, or the .NET runtime calls Suspend without caring about the
current thread state, but then it may cause a deadlock if the calling
thread also tries to enter the synchronization objects, currently held
by the suspended thread.

Small example why Suspend is so dangerous:

Think of a Print method, which enters a critical section and outputs a
string in the console window.

Thread #1 is calling:

Print("running"); // And just has entered the critical section

Now thread #2 Suspends thread #1 and calls....:

thread1->Suspend();
Print("Suspended"); // ---> Deadlock


Thread#2 tries to print the string "Suspended" by calling the Print
method, but is deadlocked, because the critical section is held by the
suspended thread. If you don't know if the Print method uses a critical
section or any other synchronization method you cannot safely call this
method. Same applies to all Win32 functions, since you don't know if
they are using synchronization objects or not.

So the thread calling suspend cannot safely call any function.
But then, what is calling Suspend good for ?


Regards Andre

 

[Willy Denoyette [MVP]]

|> Suspend/Resume are made obsolete just because of this "the willingness to
| > correct". These API's are calling the Win32 counterparts which are:
| > - not designed to be used from user code [see MSDN - SuspendThread API
<This
| > function is primarily designed for use by debuggers. It is not intended
to
| > be used for thread synchronization>]
|
| >>>> These Win32 API's have been used for years (not for thread
synchronization), but for thread control (forget synchronization that is not
the intention, thread control is). By default threads are suspended and
must be resumed and the MFC/Win32 level for example which is used in almost
all threading cases. User code uses them all the time.
| You need to be able to control your threads in .NET for various reasons,
| these API's are sometimes critical and the only means for a developer to
| accomplish specific functionality. I think they should make them so
suspend
| would stop the thread at a safe point from .NET's perspective and leave
the
| rest of the safety to the developer.

This is exactly what the CLR does, calling 'SuspendThread' and
'ResumeThread' at a safe spot, but that doesn't mean it has to be done from
"managed" user code that runs in top of the CLR.
When using MFC and Win32 you are at a different level in user space, using
Win32 you are directly controlling OS threads from your code (just like the
CLR does), when you call SuspendThread you ask the OS to suspend the OS
thread, you are assumed to know the pittfals and take measures to prevent
all sort of issues and bugs (T in Threading spell for Troubles, most of the
multithreaded applications are buggy). In managed code you aren't controling
(nor should you) OS threads, you are using "logical threads" that map to
something that might be an OS thread, but can even so be something else
(like a fiber). IMO it's up to the CLR and the FCL to make threading less
error prone and more (safely) accessible than under native code, so it's
better to remove these services, provided there are more safe alternatives,
as there are.


| > As for your suggestion to make WinFX the primary OS API, don't forget
that
|
| >>>> That's not my suggestion I heard MS has proposed that will be the
case in a future OS version. I agree with you... it is unreasonable.

Really, any signs that David Cutler going to retire? ) Mind to share the
source of such proposition? I know that Vista and Longhorn Server are still
Win32 based. IMO Win32 will survive the CLR, but as always - only the future
will tell.


Willy.

 

[Willy Denoyette [MVP]]

| WXS wrote:
|
| > [...]
| > You need to be able to control your threads in .NET for various reasons,
| > these API's are sometimes critical and the only means for a developer to
| > accomplish specific functionality. I think they should make them so
suspend
| > would stop the thread at a safe point from .NET's perspective and leave
the
| > rest of the safety to the developer.
|
| IMHO Suspend is one of the most dangerous functions in the Win32 API
| regarding deadlocks. There's no chance to safely call Suspend and even
| the .NET runtime cannot ensure that suspending a thread will be always
| safe.
|
| Either the .NET runtime must wait till the thread releases all
| synchronization objects currently held -> but what if the thread won't
| release them, or the .NET runtime calls Suspend without caring about the
| current thread state, but then it may cause a deadlock if the calling
| thread also tries to enter the synchronization objects, currently held
| by the suspended thread.
|
| Small example why Suspend is so dangerous:
|
| Think of a Print method, which enters a critical section and outputs a
| string in the console window.
|
| Thread #1 is calling:
|
| Print("running"); // And just has entered the critical section
|
| Now thread #2 Suspends thread #1 and calls....:
|
| thread1->Suspend();
| Print("Suspended"); // ---> Deadlock
|
|
| Thread#2 tries to print the string "Suspended" by calling the Print
| method, but is deadlocked, because the critical section is held by the
| suspended thread. If you don't know if the Print method uses a critical
| section or any other synchronization method you cannot safely call this
| method. Same applies to all Win32 functions, since you don't know if
| they are using synchronization objects or not.
|
| So the thread calling suspend cannot safely call any function.
| But then, what is calling Suspend good for ?
|

Very true, the CLR has taken some measures to make it 'more safe' when
suspending a thread, for instance on V2 it's made impossible for two threads
to suspend each other, the CLR also makes sure the threads don't execute any
user code after suspending an OS thread (not guaranteed by the SuspendThread
API but absolutely necessary on the CLR), but even then it's not guranteed
to cover all cases (most issues are HW related), stress failures on multi
CPU boxes (especially those equiped with multiple HT CPU's) have confirmed
that SuspendThread remains a dangerous API.

Willy.

 

[Guest]

In Win32 this works fine without trashing the kernel, in .NET we need the
same capability. Which we would have if ms didn't try to do mapping of .net
threads to underlying os threads. (Is this mapping really a good idea in all
cases, as now what would have worked, no longer does).

If .NET is going to make it's own threads, we need a way to control them in
a safe way, and suspend should suspend when safe for the CLR runtime, it can
ignore users own code and leave deadlock handling to the app developer in
that case. But the CLR should not die. There seem to be suggestions the CLR
even has an issue not suspending in the right place (while that is not a
problem for Win32).

In the scenario I am looking at I might only need to make local method
calls and maybe one system call other than suspend that should be safe.

Either fix the suspend so it suspends properly or if it does and they are
really just worried about users hurting themselves, I only have to say is
please don't hide the emergency break in my car because you think I might use
it and stop the car at the wrong time and damage something, I might need that
thing one day; Sure it would be dangerous to use that to stop the car rather
than my regular breaks... but if I don't have my regular breaks I want
something to try to stop me

[...]
You need to be able to control your threads in .NET for various reasons,
these API's are sometimes critical and the only means for a developer to
accomplish specific functionality. I think they should make them so suspend
would stop the thread at a safe point from .NET's perspective and leave the
rest of the safety to the developer.

IMHO Suspend is one of the most dangerous functions in the Win32 API
regarding deadlocks. There's no chance to safely call Suspend and even
the .NET runtime cannot ensure that suspending a thread will be always
safe.

Either the .NET runtime must wait till the thread releases all
synchronization objects currently held -> but what if the thread won't
release them, or the .NET runtime calls Suspend without caring about the
current thread state, but then it may cause a deadlock if the calling
thread also tries to enter the synchronization objects, currently held
by the suspended thread.

Small example why Suspend is so dangerous:

Think of a Print method, which enters a critical section and outputs a
string in the console window.

Thread #1 is calling:

Print("running"); // And just has entered the critical section

Now thread #2 Suspends thread #1 and calls....:

thread1->Suspend();
Print("Suspended"); // ---> Deadlock


Thread#2 tries to print the string "Suspended" by calling the Print
method, but is deadlocked, because the critical section is held by the
suspended thread. If you don't know if the Print method uses a critical
section or any other synchronization method you cannot safely call this
method. Same applies to all Win32 functions, since you don't know if
they are using synchronization objects or not.

So the thread calling suspend cannot safely call any function.
But then, what is calling Suspend good for ?


Regards Andre

 

[Guest]

First point is my understanding is suspending is not safe even from a CLR
perspective right now (they tried to suspend in a safe place but mostly only
relative to garbage collection).

If the above is true at least fix that and let me deal with the user mode
problems.
Sure MS could protect me from myself some more by tying my shoelaces
together so I can't go to work in the morning either, but is that really
productive?! From that point of view lets deprecate main() and solve all of
our problems

If .NET is going to abstract threads to .NET threads for us, it needs to
provide us a safe control method, to control those threads from external
points.

Did I mis-hear that the intention is to make WinFX the primary windows
subsystem and win32 secondary sort of like how win32 has been the primary and
posix has been a secondary subsytem, could be I misheard or misunderstood.

In either case if .NET is to be a reach full feature plaform/API
substitution for Win32 (which otherwise it seems to have every intention of
being), you need external thread controls.

|> Suspend/Resume are made obsolete just because of this "the willingness to
| > correct". These API's are calling the Win32 counterparts which are:
| > - not designed to be used from user code [see MSDN - SuspendThread API
<This
| > function is primarily designed for use by debuggers. It is not intended
to
| > be used for thread synchronization>]
|
| >>>> These Win32 API's have been used for years (not for thread
synchronization), but for thread control (forget synchronization that is not
the intention, thread control is). By default threads are suspended and
must be resumed and the MFC/Win32 level for example which is used in almost
all threading cases. User code uses them all the time.
| You need to be able to control your threads in .NET for various reasons,
| these API's are sometimes critical and the only means for a developer to
| accomplish specific functionality. I think they should make them so
suspend
| would stop the thread at a safe point from .NET's perspective and leave
the
| rest of the safety to the developer.

This is exactly what the CLR does, calling 'SuspendThread' and
'ResumeThread' at a safe spot, but that doesn't mean it has to be done from
"managed" user code that runs in top of the CLR.
When using MFC and Win32 you are at a different level in user space, using
Win32 you are directly controlling OS threads from your code (just like the
CLR does), when you call SuspendThread you ask the OS to suspend the OS
thread, you are assumed to know the pittfals and take measures to prevent
all sort of issues and bugs (T in Threading spell for Troubles, most of the
multithreaded applications are buggy). In managed code you aren't controling
(nor should you) OS threads, you are using "logical threads" that map to
something that might be an OS thread, but can even so be something else
(like a fiber). IMO it's up to the CLR and the FCL to make threading less
error prone and more (safely) accessible than under native code, so it's
better to remove these services, provided there are more safe alternatives,
as there are.


| > As for your suggestion to make WinFX the primary OS API, don't forget
that
|
| >>>> That's not my suggestion I heard MS has proposed that will be the
case in a future OS version. I agree with you... it is unreasonable.

Really, any signs that David Cutler going to retire? ) Mind to share the
source of such proposition? I know that Vista and Longhorn Server are still
Win32 based. IMO Win32 will survive the CLR, but as always - only the future
will tell.


Willy.

 

[Willy Denoyette [MVP]]

| In Win32 this works fine without trashing the kernel


NO it doesn't, these Win32 services are considered dangerous, designed to be
used with care and as I said in an earlier post designed to be used from a
debugger. Use them on modern large scale SMP boxes and your process may fail
when stressed unless you know exactly what you are doing and take some
measures. This is exactly what the SQL server team has been doing when they
integrated the CLR, they don't allow you creating threads in managed code
(unless you flag the assembly as unsafe) they don't use the CLR threadpool
they use their own, nor do they use the CLR memory manager (albeit they use
the GC) and last but not least, they load the SQLCLR code into a separate
domain that they can throw away when something bad hapens, the user only has
to provide a transaction and things aren't too bad when disaster comes
along.


, in .NET we need the
| same capability. Which we would have if ms didn't try to do mapping of
..net
| threads to underlying os threads. (Is this mapping really a good idea in
all
| cases, as now what would have worked, no longer does).
|

And to what would you map these things, .NET is an API and a run-time not an
OS nor an OS subsystem.


| If .NET is going to make it's own threads,

How do you want .NET to make his own threads? Do you want to bypass the OS
entirely.


we need a way to control them in
| a safe way, and suspend should suspend when safe for the CLR runtime, it
can
| ignore users own code and leave deadlock handling to the app developer in
| that case. But the CLR should not die.

The CLR is not a distinct part in the system, it's just a bunch of libraries
loaded into your process (a run-time) offering some services like JIT
compiling, automatic memory management etc...., the CLR can't die, your
process will die or better it won't make progress as it may deadlock.


There seem to be suggestions the CLR
| even has an issue not suspending in the right place (while that is not a
| problem for Win32).

Win32 has the same issues believe me, as I said before, see the description
of the SuspendThread API in MSDN. SuspendThread should only be used from
debuggers, user programs should signal the target thread to suspend itself,
but you should never call SuspendThread to suspend another thread.
Also, keep in mind that since these API's were invented things have changed
dramatically, superscallar HT and multicore CPU's did not exists, same for
APIC used these day's.


|
| In the scenario I am looking at I might only need to make local method
| calls and maybe one system call other than suspend that should be safe.
|
| Either fix the suspend so it suspends properly or if it does and they are
| really just worried about users hurting themselves,

There is nothing to fix, simply don't use it to suspend another thread.
Don't suspend a thread that runs third party code you don't control, you
actually don't know what the code looks like it might hold a kernel lock (or
shiver a loader lock), don't expect Suspend to stop the thread cold at a
safe point (whatever that may be in your third party code), it isn't even
guaranteed that the target thread immediately stops executing user code
after the SuspendThread API returns (on HT or multicores it won't unless you
call Win32 GetThreadContext after SuspendThread, bet you don't do this in
your native code!).



I only have to say is
| please don't hide the emergency break in my car because you think I might
use
| it and stop the car at the wrong time and damage something, I might need
that
| thing one day; Sure it would be dangerous to use that to stop the car
rather
| than my regular breaks... but if I don't have my regular breaks I want
| something to try to stop me

Don't know about "emergency breaks" in a car, all I know is a "hand break"
which is also not designed to stop a moving car.


Willy.

 

[Willy Denoyette [MVP]]

| First point is my understanding is suspending is not safe even from a CLR
| perspective right now (they tried to suspend in a safe place but mostly
only
| relative to garbage collection).

Well largely it relates to GC, but the CLR uses these Win32 API's to control
the Win32threadpool as well, only it does so with great care, it can do it
"almost" safely because it controls it's run-time environment it knows
exactly when to suspend because the JIT marks the safe points to do so. Note
that the CLR won't suspend a thread which is actually executing unmanaged
code for the same reason that it's considers it unsafe to do so, the CLR is
not controlling the code no safe points are signaled so he keeps the thread
running while the GC runs and other managed threads are suspended.


|
| If the above is true at least fix that and let me deal with the user mode
| problems.
| Sure MS could protect me from myself some more by tying my shoelaces
| together so I can't go to work in the morning either, but is that really
| productive?! From that point of view lets deprecate main() and solve all
of
| our problems
|
| If .NET is going to abstract threads to .NET threads for us, it needs to
| provide us a safe control method, to control those threads from external
| points.

Well it does provide alternatives right?

| Did I mis-hear that the intention is to make WinFX the primary windows
| subsystem and win32 secondary sort of like how win32 has been the primary
and
| posix has been a secondary subsytem, could be I misheard or misunderstood.
|

I don't know, Again where did you hear this?

| In either case if .NET is to be a reach full feature plaform/API
| substitution for Win32 (which otherwise it seems to have every intention
of
| being), you need external thread controls.
|

..NET was not designed to replace Win32, it's just an OO API wrapping a
functional level API a runtime and toolset nothing more nothing less. Take
a look at Vista, The native API set (including Win32) is extended with ~5000
API's, all NetFX (or better .NET Framework V3) does is present a nice OO API
in top of it, but no-one stops you from directly calling the API's from
unmanaged code, after all ISO/C++ is stall part of VS, right?.
A part of the developers community don't care about .NET another part can't
consider it because it doesn't offer the low level functionality they need,
others don't like it and stay with unmanaged code and finally everyone is
happy.

Willy.

 

[Andre Kaufmann]

[...]

Very true, the CLR has taken some measures to make it 'more safe' when
suspending a thread, for instance on V2 it's made impossible for two threads
to suspend each other, the CLR also makes sure the threads don't execute any
user code after suspending an OS thread (not guaranteed by the SuspendThread
API but absolutely necessary on the CLR),

Thanks for the info. Didn't know that they already implemented that.

but even then it's not guranteed
to cover all cases (most issues are HW related), stress failures on multi
CPU boxes (especially those equiped with multiple HT CPU's) have confirmed
that SuspendThread remains a dangerous API.

Very true. It's safer to call it in .NET than Win32, but it's still
unsafe. And (with the Suspend behavior in .NET you described above) the
Suspend method in .NET cannot suspend a thread in a guaranteed time, if
the thread doesn't return from native code.

Willy.

Andre

 

[Andre Kaufmann]

In Win32 this works fine without trashing the kernel, in .NET we need the

I've been burned by a deadlock, when I've used Suspend in my first
multithreading application, 10 years ago. I simply called a socket
function in the suspended thread, and in the one which has called
suspend I did also call a socket function and ---> boom got a deadlock
in the Ws2_32.dll. After that I deprecated Suspend in our code and won't
use it anymore for synchronization.

same capability. Which we would have if ms didn't try to do mapping of .net
threads to underlying os threads. (Is this mapping really a good idea in all
cases, as now what would have worked, no longer does).
[...]

They could perhaps use fibers and do their own thread scheduling, but
the problem would be the same. One of these .NET threads would call
suspend, and the scheduling thread wouldn't schedule the suspended
thread anymore. What would be the difference if the OS is scheduling or
..NET ?
In combination with native code the .NET runtime cannot make any
assumptions and in .NET only code there might also be pitfalls, where
you may deadlock your application (as Willy alrady pointed out).

I don't see a reliable and easy solution :-(

Andre

 

[Guest]

Some additional research into this does suggest they could make it safe
enough to use, but probably wanted to avoid investing the time to do so.
Sort of gives me a sad feeling about the .NET platform and it's ability to
handle any task thrown at it. I now have one situation I can not solve
easily due to this.