.NET糟糕的线程架构？ [英] .NET Poor threading architecture?

问题描述

当我看到.NET 2.0中的内容就像暂停/恢复一样，因为

MS给出的公开理由他们认为人们正在使用它们

不合适..使用互斥锁，监视器和其他同步对象

而不是哦，顺便说一下你不应该使用它们因为它们可能导致死锁和其他主要问题，尖叫bug或线程架构

问题以及缺乏纠正的意愿或优先权。实际上那些API的'b
用于控制线程的启动和停止，例如一个

操作系统（确实MS知道一些关于:) :)（我认为

他们应该留下这些并解决这个问题。）


当然还有另一个问题，因为线程是可以中断的，因为

到gc后他们必须重新获得锁定，因此可以重新订购

然后线程变得不公平。


鉴于这些和其他问题我认为MS应该重新考虑将WinFX作为主要操作系统的主要操作系统API，它开始吓唬我的其他内容是什么

我们还没有发现了。

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.

推荐答案

哎呀，这看起来非常熟悉。我几乎发誓这是一个重复的帖子

来自另一个新闻组的帖子...


-

HTH ，


Kevin Spencer

微软MVP

专业鸡肉沙拉炼金术士


A终身由

组成。很短暂的时刻。


WXS < WX*@discussions.microsoft.com>在留言中写道

news：18 ********************************** @ microsof t.com ...

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.

"WXS" <WX*@discussions.microsoft.com> wrote in message
news:18**********************************@microsof t.com...

当我看到.NET 2.0中的内容就像暂停/恢复一样因为MS给出的公开理由他们认为人们正在使用它们
不恰当地..使用互斥锁，监视器和其他同步对象而不是哦你不应该使用它们，因为它们可能导致死锁和其他主要问题，尖叫错误或线程架构 API用于控制线程的启动和停止，例如，操作系统（确实MS知道一些关于:) :)（我认为他们应该留下这些并解决这个问题。）

当然还有另一个问题，因为线程是可以中断的，因为它们必须重新使用gc -acquire后来锁定，因此可以重新订购
然后线程变得不公平。

鉴于这些和​​其他问题，我认为MS应该重新考虑让WinFX成为封面下还有什么内容
我们还没有找到。

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.

暂停/恢复被淘汰只是因为这个愿意

正确。这些API正在调用Win32对应物：

- 不是用于从用户代码中使用[参见MSDN - SuspendThread API<这个

函数主要是设计用于调试器。它并不打算将

用于线程同步>]

- 从高度虚拟化的
环境（如.NET）中使用不当时被认为是危险的。


Thread.Abort同样如此，但不幸的是这个不能制作

已过时。

授予，这些服务应该永远不会被包含在.NET中，它们是设计错误，但你不能构建如此复杂的系统而不会造成

错误。

至于你的建议，让WinFX成为主要的操作系统API，不要忘了

WinFX是Win32（在Windows上）的用户级OO API构建，那是'<完全是CLR和FCL的角色 -
向用户提供OO级别的API，即虚拟化底层OS服务的
。你的建议是

将它移到系统级别并期望所有应用程序都被重写

使用某种托管语言，或者更糟糕的是，通过<惩罚本机应用程序br />
通过反向thunking层调用，不用了。


Willy。


" WXS" < WX*@discussions.microsoft.com>在留言中写道

news：18 ********************************** @ microsof t.com ...

|当我看到.NET 2.0中的内容就像暂停/恢复因为

|而过时MS给出的公共理由他们认为人们正在使用它们

|不恰当地..使用互斥锁，监视器和其他同步对象

|相反，哦顺便说一下你不应该使用它们，因为它们可以导致

|僵局和其他主要问题，尖叫bug或线程架构

|问题，缺乏正确的意愿或优先权。实际上那些

API'的

|用于控制像umm这样的线程的启动和停止

an

|操作系统确实（确实MS知道这个:) :)（我认为

|他们应该留下这些并解决这个问题。）

|

|当然还有另一个问题，因为线程是可中断的

到期

|到了gc，他们必须重新获得锁定，因此可以重新订购

|然后线程变得不公平。

|

|鉴于这些和​​其他问题我认为MS应该重新考虑使WinFX成为

|主操作系统API，它开始吓唬我在

封面下的其他内容

|我们还没有找到。

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.

"WXS" <WX*@discussions.microsoft.com> wrote in message
news:18**********************************@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.

>暂停/恢复因为

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

correct的意愿而变得过时。这些API正在调用Win32对应物：
- 不是用于用户代码[请参阅MSDN - SuspendThread API<此
函数主要供调试器使用。它不打算用于线程同步>]

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>]

这些Win32 API''已经使用了多年（不是用于线程同步），但是对于线程控制（忘记同步不是意图，线程控制是）。默认情况下，线程被挂起并且必须恢复，并且MFC / Win32级别例如在几乎所有线程情况下都使用。用户代码始终使用它们。
您需要能够出于各种原因控制.NET中的线程，

这些API有时是关键的，而且是开发人员的唯一方法

完成特定功能。我认为他们应该让他们如此暂停

会在.NET的视角下将线程停在一个安全的位置，并将

其余的安全保留给开发人员。


至于你的建议让WinFX成为主要的操作系统API，不要忘记
这不是我的建议我听过MS提出的将是未来操作系统版本中的案例。我同意你的观点......这是不合理的。

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.

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.

" Willy Denoyette [MVP]"写道：

暂停/恢复已经过时，因为这个愿意
正确。这些API正在调用Win32对应物：
- 不是用于用户代码[请参阅MSDN - SuspendThread API<此
函数主要供调试器使用。它不打算用于线程同步>]
- 从.NET等高度虚拟化的环境中不恰当地使用时被认为是危险的。

同样的道理对于Thread.Abort，但遗憾的是这个不能过时。
当然，这些服务应该永远不会包含在.NET中，它们是设计错误，但你不能构建这样复杂的系统而不会出现错误。
至于你的建议，让WinFX成为主要的OS API，不要忘记，WinFX是Win32之上的用户级OO API构建（在Windows上），确切地说就是CLR和FCL的角色 - 向用户提供虚拟化底层OS服务的OO级API。你的建议是将它移动到系统级别并期望使用某种托管语言重写所有应用程序，或者更糟糕的是，通过反向thunking通过
调用惩罚本机应用程序层，不，谢谢。

威利。

WXS < WX*@discussions.microsoft.com>在消息中写道
新闻：18 ********************************** @ microsof t.com。 ..
|当我看到.NET 2.0中的东西就像因为
|而暂停/恢复的过时MS给出的公众理由认为人们正在使用它们
|不恰当地..使用互斥锁，监视器和其他同步对象
|相反，哦，顺便说一句，你不应该使用它们，因为它们可以导致
|僵局和其他主要问题，尖叫bug或线程架构
|问题，缺乏正确的意愿或优先权。实际上那些
API'
|用于控制线程的启动和停止，例如，

操作系统确实（确实MS知道这个:) :)（我认为
|他们应该留下这些并解决这个问题。）
|
|当然还有另一个问题，因为线程是可中断的
由于
他们必须重新获得锁定，因此可以重新订购
|然后线程变得不公平。
|
|考虑到这些和其他问题，我认为MS应该重新考虑制作WinFX
|主操作系统API，它开始吓唬我在
封面下还有什么内容我们还没有找到。

"Willy Denoyette [MVP]" wrote:
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.

"WXS" <WX*@discussions.microsoft.com> wrote in message
news:18**********************************@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.

这篇关于.NET糟糕的线程架构？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！