非托管 dll,挂起/等待/缓慢

发布于 2024-12-06 21:27:08 字数 383 浏览 0 评论 0 原文

我有一个在 IIS 7 上运行的 asp.net 中工作的非托管 dll。大多数情况下,在几个请求之后,应用程序会挂起大约一分钟,然后再继续或显示错误。 我是否必须处置、释放或调用 DLL different?

[DllImport("Fan.dll", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Ansi, SetLastError = true, ExactSpelling = true)]
public static extern int GET_CALCULATION_FAN_ALONE_PC(ref string input, string buffer);

任何帮助将不胜感激!

I've got an unmanaged dll working in asp.net running on IIS 7. Most of the time after a few request the application hangs for about a minute before continue or showing an error.
Do I have to dispose, release or call the DLLdifferent?

[DllImport("Fan.dll", CallingConvention = CallingConvention.StdCall, CharSet = CharSet.Ansi, SetLastError = true, ExactSpelling = true)]
public static extern int GET_CALCULATION_FAN_ALONE_PC(ref string input, string buffer);

Any help would be appreciated!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

苹果你个爱泡泡 2024-12-13 21:27:08

看来非托管代码不是线程安全的。这是关于您遇到的问题的很好的讨论:

来自 http://social.msdn.microsoft.com/Forums/en-US/asmxandxml/thread/504cdc70-16f1-4c39-a0c0-1d47b2a64f7b/

需要注意的是非托管代码可能不是线程安全的。在 Web 服务的上下文中,每个请求都将到达不同的线程,并且非托管代码可能无法处理该问题。这些崩溃可能是由未经多线程环境测试的代码引起的内存损坏的迹象。

对于您可能希望从托管代码调用的非托管代码,存在一些不同的线程问题:

1.
同时在多个线程上调用非托管代码可能不安全。这个问题可以通过正确的锁定来解决。我强调正确。
2.
非托管代码可能以某种方式依赖于始终在同一个单线程上调用。这种情况不太可能发生,但也是有可能的。这一问题无法在 ASP.NET Web 应用程序或 Web 服务应用程序中直接解决,除非您以某种方式在应用程序启动时启动一个线程,并将对此代码的所有请求编组到该线程。
3.
非托管代码可以是 COM 代码并且依赖于在特定单元中运行。我不知道是否有解决办法。

这个问题不会有一个通用的解决方案,至少不是你能解决的。一般的解决方案是非托管代码的开发人员或供应商确保他们的代码可以安全地从多个线程上的托管代码调用。在他们在该环境中彻底测试代码之前,您无法真正确定它是否有效。

It seems that the unmanged code is not thread safe. Here is a good discussion on the issue you are having:

Answers From http://social.msdn.microsoft.com/Forums/en-US/asmxandxml/thread/504cdc70-16f1-4c39-a0c0-1d47b2a64f7b/

The thing to be careful about is that the unmanaged code may not be thread-safe. In the context of a web service, each request will arrive on a different thread, and the unmanaged code may not handle that. These crashes may be signs of memory corruption caused by code that has not been tested in a multithreaded environment.

There are a couple of different threading issues with unmanaged code that you might like to call from managed code:

1.
It might not be safe to call the unmanaged code on more than one thread at the same time. This issue can be solved with correct locking. I stress correct.
2.
The unmanaged code may somehow depend on being called on the same single thread all the time. This is less likely, but possible. This cannot be solved directly within an ASP.NET web application or web service application, unless you somehow start up a thread when the application starts, and marshall all requests for this code to that one thread.
3.
The unmanaged code may be COM code and depend on running in a particular apartment. I don't know if there's a solution to that.

There will not be a general solution to this problem, at least not that you can solve. The general solution is for the developer or vendor of the unmanaged code to make their code safe to be called from managed code on multiple threads. Until they've thoroughly tested their code in that environment, you can't really be sure it will work.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文