.NET poor threading architecture?

[WXS]

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]

At some point every developer has to take responsibility for what he/she
does, what he/she uses, his/her understanding of what he/she does and/or
uses, and the consequences of his/her decisions with regards to what he/she
develops.

The more powerful a technology is, the more dangerous it is, in that it has
a greater capacity to cause damage if misused. Atomic power comes to mind.
Pointers come to mind.

The more complex a technology is, the more permutations there exist of
complexity in that which employs the technology. The more complex the
result, the greater the possibility that there will be problems with it.
Threading comes to mind.

Now, Microsoft could try to protect us all by attempting to hide complexity
and subvert power in the tools they create. In fact, they do, to a certain
extent. Much of the Windows API is still missing in the .Net Framework. Real
pointers are extremely difficult to get at. Low-level threading is
discouraged. But guess what would happen if they went too far with this
idea? Their business would go to the competition that provides the power and
complexity we all crave.

So, getting back to my first point...

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

A lifetime is made up of
Lots of short moments.

"WXS" <WX*@discussion s.microsoft.com > wrote in message
news:3D******** *************** ***********@mic rosoft.com...

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.

[WXS]

Basically microsoft for the suspend/resume api's has to at least fix it so
that suspend happens at a safe point from the .net perspective, everything
else leave up to the developer and let them do what they need to do.

The probablem apparently is with the suspend api you can cause .net deadlock
as it allows suspends while it may be holding security locks or even type
constructor instantiation locks that could deadlock other code. If they
could stop at a safe point then the API's would still be plenty useful, but
not for the reasons they suggest.

Win32 API can suspend a resume a thread fine.. why? because it makes sure
the thread isn't holding from an OS perspective any kernel level locks that
could freeze the OS prior to suspending it. Could they do this for .NET...
probably unless there is a significant architecture issue with their
threading model I would guess. Is it easy (No... but worth it to make .net a
serious development platform.).

"Kevin Spencer" wrote:

At some point every developer has to take responsibility for what he/she
does, what he/she uses, his/her understanding of what he/she does and/or
uses, and the consequences of his/her decisions with regards to what he/she
develops.

The more powerful a technology is, the more dangerous it is, in that it has
a greater capacity to cause damage if misused. Atomic power comes to mind.
Pointers come to mind.

The more complex a technology is, the more permutations there exist of
complexity in that which employs the technology. The more complex the
result, the greater the possibility that there will be problems with it.
Threading comes to mind.

Now, Microsoft could try to protect us all by attempting to hide complexity
and subvert power in the tools they create. In fact, they do, to a certain
extent. Much of the Windows API is still missing in the .Net Framework. Real
pointers are extremely difficult to get at. Low-level threading is
discouraged. But guess what would happen if they went too far with this
idea? Their business would go to the competition that provides the power and
complexity we all crave.

So, getting back to my first point...

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

A lifetime is made up of
Lots of short moments.

"WXS" <WX*@discussion s.microsoft.com > wrote in message
news:3D******** *************** ***********@mic rosoft.com...

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.