这个问题的可行解决方案?

发布于 2024-10-25 20:11:50 字数 541 浏览 7 评论 0原文

我通过多层第三方代码从我的一段代码进行调用,并且通过调用我编写的一些代码,该调用在某个时刻返回到我的代码中。

换句话说,代码调用链如下所示:

My code #1 --> 3rd party code --> My code #2

不幸的是,我传递给第 3 方代码的任何内容都没有传递给第二段代码,因此我没有任何东西可以将第一段和第二段代码连接在一起,除了以下事实:代码在同一个线程上运行。

所以我想知道在类的静态字段上简单地使用 [ThreadStatic] 是否是一个可行的解决方案?

由于代码也在 Web 应用程序中运行,因此我不能仅使用静态字段来实现此目的,因为每个用户/会话需要访问的值(对象)都不同。

IE。我会做这样的事情:

internal static class DataHolder
{
    [ThreadStatic]
    internal static ClassName FieldName;
}

还有其他解决方案吗?

I am calling from one piece of my code through several layers of 3rd party code, and the call surfaces back into my code at some point by calling some code I've written.

In other words, the code call chain looks like this:

My code #1 --> 3rd party code --> My code #2

Unfortunately, nothing I pass to the 3rd party code is given to that second piece of code so I have nothing to tie the first piece and the second piece together, except for the fact that the code runs on the same thread.

So I was wondering if simply using [ThreadStatic] on a static field on a class would be a viable solution to this?

Since the code also runs in a web application, I cannot just use a static field for this, since the value I need access to (an object) is different for each user/session.

ie. I would do something like this:

internal static class DataHolder
{
    [ThreadStatic]
    internal static ClassName FieldName;
}

Are there other solutions to this?

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

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

发布评论

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

评论(4

ぶ宁プ宁ぶ 2024-11-01 20:11:50

与建议这没问题的其他答案相反,在 ASP.NET 应用程序中使用 ThreadStatic 或 ThreadLocal时,您应该非常小心。

ASP.NET 利用线程敏捷性,这意味着同一请求可能由多个线程处理。为了安全起见,您需要打破封装并将项目存储在当前的 HttpContext 中,而不是使用 ThreadStaticThreadLocal

internal static class DataHolder
{
    internal static ClassName PropertyName
    {
        get { return (ClassName)System.Web.HttpContext.Current.Items["foo"]; }
        set { System.Web.HttpContext.Current.Items["foo"] = value; }
    }
}

不幸的是,这种线程敏捷性“功能”的记录非常少。我有理由确信线程切换只能在生命周期中的某些点发生,而不是任意发生,因此根据代码在生命周期中的具体使用方式和位置,您可能可以安全地使用 ThreadStaticThreadLocal

我会尝试挖掘一些链接......

In contrast to the other answers suggesting that this is ok, you should be very careful about using ThreadStatic or ThreadLocal<T> in an ASP.NET application.

ASP.NET utilises thread-agility, meaning that the same request can potentially be handled by several threads. To be safe you'd need to break encapsulation and store your items in the current HttpContext, rather than using ThreadStatic or ThreadLocal<T>:

internal static class DataHolder
{
    internal static ClassName PropertyName
    {
        get { return (ClassName)System.Web.HttpContext.Current.Items["foo"]; }
        set { System.Web.HttpContext.Current.Items["foo"] = value; }
    }
}

Unfortunately this thread-agility "feature" is very poorly documented. I'm reasonably sure that the thread switch can only happen at certain points in the lifecycle, not arbitrarily, so depending on exactly how and where in the lifecycle the code is used you might be safe with ThreadStatic or ThreadLocal<T>.

I'll try to dig out some links...

旧人哭 2024-11-01 20:11:50

是的。 ThreadStatic 可以实现这一点。您可能需要研究 ThreadLocal,它简化了线程静态变量的使用。

Yes. ThreadStatic will work for that. You might want to look into ThreadLocal, which simplifies working with thread static variables.

放赐 2024-11-01 20:11:50

是的,[ThreadStatic] 应该在您描述的场景中工作,如果您可以绝对确定第 3 方代码始终在您调用第 3 方代码的同一线程上回调您。在许多异步回调模型中,这通常无法得到保证。如果回调被严格定义为同步回调,那么你可能没问题。

Yes, [ThreadStatic] should work in the scenario you describe if you can be absolutely certain that the 3rd party code always calls you back on the same thread that you called into the 3rd party code on. In many async callback models, this is often not guaranteed. If the callback is strictly defined as a synchronous callback, then you're probably ok.

拍不死你 2024-11-01 20:11:50

.NET 4 的 ThreadLocal如本问题所述:

是 C# 中不同线程之间共享的静态类

但是,我自己也曾经历过这种情况 - 我最终走上了静态路线。它有效并且安全,因为它是可管理的状态。

ThreadLocal<T> for .NET 4 as mentioned in this question:

are static classes shared among different threads in C#

However, having been in that boat myself - I ended up going down the static route. It worked and was safe because it was manageable state.

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