threadpool是否利用内存屏障？ [英] Does threadpool utilize a memory barrier?
问题描述
如果我有一个工作对象通过
QueueUserWorkItem执行并且工作进程只访问该对象的
实例数据我仍然会发生这种情况。可能必须锁定，因为对象构造函数
在另一个线程中运行。那个isfpre意味着没有锁定线程池线程可能无法获得实例的正确视图
数据。 （具体来说，它可能仍然被视为空）。
之前有过吗？
谢谢，
汤姆
汤姆，
不，它没有。一个对象不能在构造函数中被任何
其他线程访问但是正在构造对象的线程。
如果要分配对象在ThreadPool中由两个
不同方法共享的字段，然后是，它是可能的。但是，你应该封装对属性中字段的访问权限，这将保证你只有一个实例（它会锁定某些东西，检查是否
null，并在必要时创建实例。
希望这会有所帮助。
-
- Nicholas Paldino [.NET / C＃MVP]
- mv*@spam.guard.caspershouse.com
< NO *********** @ lycos.com>在消息中写道
news：11 ********************** @ o13g2000cwo.googlegr oups.com ...对我来说，如果我有一个工作对象通过QueueUserWorkItem执行并且工作proc只访问该对象的实例数据，那么我仍然需要锁定因为该对象构造函数
在另一个线程中运行。 thatfpre意味着没有锁定线程池线程可能无法获得实例
数据的正确视图。 （具体来说，它可能仍然被视为空）。
以前是否曾经出现过？
谢谢，汤姆
< NO *********** @ lycos.com>写道：如果我有一个工作对象通过QueueUserWorkItem执行并且工作进程只访问该对象的实例数据我仍然可能必须锁定因为对象构造函数在另一个线程中运行。 thatfpre意味着没有锁定线程池线程可能无法获得实例
数据的正确视图。 （具体来说，它可能仍然被视为空）。
以前是否曾经出现过？
是的，已经问道，老实说，这不是一件令人满意的答案。我非常非常怀疑线程池是否可以工作，而不会在某处涉及内存屏障 - 毕竟，
代表本身必须通过在线程之间，所以必须有一些* b $ b * *同步。话虽如此，文档并没有b $ b指定它。
-
Jon Skeet - < sk * **@pobox.com>
http://www.pobox.com/ ~Sibet 博客： http://www.msmvps.com/jon。双向飞碟
如果回复小组，请不要给我发邮件
" Jon Skeet [C＃MVP]" < SK *** @ pobox.com>在消息中写道
新闻：MP ************************ @ msnews.microsoft.c om ...< NO *********** @ lycos.com>写道：如果我有一个工作对象通过QueueUserWorkItem执行并且工作进程只访问该对象的实例数据我仍然可能必须锁定因为对象构造函数在另一个线程中运行。 thatfpre意味着没有锁定线程池线程可能无法获得实例
数据的正确视图。 （具体来说，它可能仍然被视为空）。
以前是否曾经出现过这个问题？
是的，有人问过这个问题，并且说实话，没有令人满意的答案。我非常非常怀疑线程池是否能够工作而没有涉及某处的内存屏障 - 毕竟，委托本身必须在线程之间传递，所以必须有
*有些*同步。话虽如此，文档并没有明确说明。
只需添加：自文档和规范以来，据我所知
无论如何，没有定义它，你真的应该确保*你的*代码是安全的。
如果没有具体说明我可以看到微妙的问题出现
平台或实施。
It occurs to me that if I have a work object that gets executed via
QueueUserWorkItem AND the work proc accesses only that object''s
instance data I STILL may have to lock because the object constructor
ran in a different thread. That therefpre means that without a lock
the threadpool thread might not get the correct view of the instance
data. (Specifically, it might still be seen as null).
Has this ever come up before?
Thanks,
Tom
Tom,
No, it has not. An object can not be accessed in a constructor by any
other thread BUT the thread that the object is being constructed on.
If you are assigning the object to a field that is shared by two
different methods in the ThreadPool, then yes, it is possible. However, you
should encapsulate access to the field in a property, which will guarantee
that you have only one instance (it will lock on something, check to see if
null, and create the instance if necessary).
Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
<NO***********@lycos.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...It occurs to me that if I have a work object that gets executed via
QueueUserWorkItem AND the work proc accesses only that object''s
instance data I STILL may have to lock because the object constructor
ran in a different thread. That therefpre means that without a lock
the threadpool thread might not get the correct view of the instance
data. (Specifically, it might still be seen as null).
Has this ever come up before?
Thanks,
Tom
<NO***********@lycos.com> wrote:It occurs to me that if I have a work object that gets executed via
QueueUserWorkItem AND the work proc accesses only that object''s
instance data I STILL may have to lock because the object constructor
ran in a different thread. That therefpre means that without a lock
the threadpool thread might not get the correct view of the instance
data. (Specifically, it might still be seen as null).
Has this ever come up before?
Yes, it''s been asked, and to be honest there isn''t a satisfactory
answer. I very, very much doubt that the thread-pool is able to work
without there being a memory barrier involved somewhere - after all,
the delegate itself has to be passed between threads, so there must be
*some* synchronization. Having said that, the documentation doesn''t
specify it.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...<NO***********@lycos.com> wrote:It occurs to me that if I have a work object that gets executed via
QueueUserWorkItem AND the work proc accesses only that object''s
instance data I STILL may have to lock because the object constructor
ran in a different thread. That therefpre means that without a lock
the threadpool thread might not get the correct view of the instance
data. (Specifically, it might still be seen as null).
Has this ever come up before?
Yes, it''s been asked, and to be honest there isn''t a satisfactory
answer. I very, very much doubt that the thread-pool is able to work
without there being a memory barrier involved somewhere - after all,
the delegate itself has to be passed between threads, so there must be
*some* synchronization. Having said that, the documentation doesn''t
specify it.
Just to add on: Since the documentation and specification, to my knowledge
anyway, don''t define it, you really should ensure *your* code is safe.
Without a specificiation I could see subtle issues coming up across
platforms or implementations.
这篇关于threadpool是否利用内存屏障？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
