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*@discussions.microsoft.com> wrote in message
news:3D**********************************@microsof t.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.