需要读锁吗？ [英] read lock needed?
问题描述
如果我有很多线程写入变量（例如var ++）和另一个线程
在间隔基础上读取它。 />
对于那些编写线程的人，我知道我需要锁定，或者它的值可能更低
（即使我认为它几乎不会发生在++操作中因为它是
不是像读取值并等待一段时间然后回写
多线程环境，BTW，这种理解是对的吗？）。
我的问题，对于阅读线程，我需要锁定吗？
如果锁定仍然是必须的，那么什么时候我可以接受竞争条件，
只是读取值不要太旧，例如低于其当前值的2或更多。新的读取应该永远不会少于旧的读取。
如果我在读取线程中不使用锁定，我是否必须使用volatile作为var，
否则它有可能无法读取当前值？
非常感谢！
Ryan Liu写道：
如果我有很多线程写入变量（例如var ++）和另一个线程
在间隔基础上读取它。
对于那些写线程，我知道我需要锁定，或者它的值可能更低
（即使我认为它几乎不会发生在++操作中，因为它是
不是像读取值并等待一段时间然后回写
多线程环境，BTW，这种理解是对吗？）。
++运算符不产生原子读 - 增量 - 写动作
所以你肯定有可能看到变量的值比可能的低（或可能更高）
值。
我的问题，对于阅读线程，我需要锁吗？
好吧，技术上没有。至少你需要使用一个
易失性读取机制，但是如果你继续使用锁定它是最好的
，特别是如果你' '已经将它们用于写作线程了。
如果锁定仍然是必须的，那么什么时候我可以接受竞争条件，
只是读取值不要太旧，例如低于其当前值的2或更多。新阅读应该永远不会少于旧读。
如果你正确使用锁，这是不可能的。
如果我没有在读取线程中使用锁定，我是否必须使用volatile作为var，
否则它有可能不读取当前值？
这是正确的。但是，我再次使用锁
Ryan Liu< ad ******** @ online.sh.cnwrote：
如果我有很多线程写入变量（例如var ++）和另一个线程
在间隔基础上读取它。
对于那些写线程，我知道我需要锁定，或者它的值可能更低
（即使我认为它几乎不会发生在++操作中，因为它
不是像读取值并等待一段时间然后回写
多线程环境，BTW，这种理解对吗？）。
我的问题，对于阅读线程，我需要锁吗？
是的，如果你想确保你看到最近的价值。
如果锁是仍然是必须的，当我能接受竞争条件时，
只是读取值不要太旧，例如低于其当前值的2或更多。新阅读应该永远不会少于旧阅读。
在一个帖子中，我不认为*你应该看到一个值
后跟一个较小的值。在多个线程中你可以。
如果我不在锁读线程中使用锁，我是否必须使用volatile作为var，
否则它有可能不读取当前值？
使用volatile意味着你不需要锁定阅读线程。
另一种方法是使用Thread .MemoryBarrier（）。
但是，我建议只使用锁来访问
变量：你有什么证据可以建议这会是一个坏主意吗？
-
Jon Skeet - < sk *** @ pobox.com>
http://www.pobox.com/~skeet 博客： http://www.msmvps.com/jon.skeet
如果回复小组，请不要给我发邮件
" Jon Skeet [C＃MVP]" < sk *** @ pobox.com ????
新闻：MP ************************ @ msnews.microsoft.c om ...
Ryan Liu< ad ******** @ online.sh.cnwrote：
< blockquote class =post_quotes>
如果我有很多线程写入变量（例如var ++）而另一个
thread
在间隔基础上读取它。
对于那些写线程，我知道我需要锁定，或其值可能是
lower
（即使我认为它几乎不会发生++操作，因为
它是
不是像读取值并等待一段时间然后写回
多线程环境，顺便说一句，这个理解是对的吗？）。
我的问题，对于阅读线程，我需要锁吗？
是的，如果你想确保你看到最近的价值。
如果锁是仍然是必须的，当我能接受竞争条件时，
只是读取值不要太旧，例如小于
2或更多其
当前值。新阅读应该永远不会少于旧阅读。
在一个帖子中，我不认为*你应该看到一个值
后跟一个较小的值。你可以在多个线程中。
如果我在读取线程中不使用锁定，我是否必须使用volatile来获取
var，
否则它有可能无法读取当前值？
使用volatile意味着你不需要锁定阅读线程。
另一种方法是使用Thread .MemoryBarrier（）。
但是，我建议只使用锁来访问
变量：你有什么证据可以建议这会是一个坏主意吗？
实际上，没有。我只是锁可能比挥发更昂贵。这是一个
客户端/服务器应用程序，我希望有一天能同时支持500个/ b $ b客户端（线程）。
谢谢，Jon！
Ryan
-
Jon Skeet - < sk *** @ pobox.com>
http：/ /www.pobox.com/~skeet 博客： http：// www .msmvps.com / jon.skeet
如果回复该群组，请不要给我发邮件
Hi,
If I have many threads write to a variable(e.g. var++) and another thread
read it on an interval base.
For those writing thread, I know I need lock, or its value could be lower
( even I think it is mostly not going to happen for ++ operation since it is
not something like read a value and wait sometime then write back in
multiple threading environment, BTW, is this understanding right?).
My question, for the reading thread, do I need lock?
If a lock is still a must, what about when I can accept race condition,
just the read value don''t to be "too old", e.g. 2 or more less than the its
current value. And new read should never less then old read.
If I don''t use lock in read thread, do I have to use volatile for the var,
otherwise it has the potential not to read the current value?
Thanks a lot!
Ryan Liu wrote:Hi,
If I have many threads write to a variable(e.g. var++) and another thread
read it on an interval base.
For those writing thread, I know I need lock, or its value could be lower
( even I think it is mostly not going to happen for ++ operation since it is
not something like read a value and wait sometime then write back in
multiple threading environment, BTW, is this understanding right?).
The ++ operator does not produce an atomic read-increment-write action
so it certainly is possible that you''d see a lower (or possibly higher)
value for the variable than what it''s suppose to be.
My question, for the reading thread, do I need lock?Well, technically no. At the very least you do need to use one of the
volatile read mechanisms, but it''s best if you go ahead and use a lock
especially if you''re already using them for the writing threads.
If a lock is still a must, what about when I can accept race condition,
just the read value don''t to be "too old", e.g. 2 or more less than the its
current value. And new read should never less then old read.
That''s impossible if you use locks correctly.
If I don''t use lock in read thread, do I have to use volatile for the var,
otherwise it has the potential not to read the current value?
That''s correct. But again, I''d use a lock
Ryan Liu <ad********@online.sh.cnwrote:If I have many threads write to a variable(e.g. var++) and another thread
read it on an interval base.
For those writing thread, I know I need lock, or its value could be lower
( even I think it is mostly not going to happen for ++ operation since it is
not something like read a value and wait sometime then write back in
multiple threading environment, BTW, is this understanding right?).
My question, for the reading thread, do I need lock?Yes, if you want to make sure you see a recent value.
If a lock is still a must, what about when I can accept race condition,
just the read value don''t to be "too old", e.g. 2 or more less than the its
current value. And new read should never less then old read.Within one thread, I don''t *think* you should ever see one value
followed by a smaller one. Within multiple threads you could.
If I don''t use lock in read thread, do I have to use volatile for the var,
otherwise it has the potential not to read the current value?Using volatile would mean you wouldn''t need to lock the reading thread.
An alternative is to use Thread.MemoryBarrier().
However, I''d suggest just using the lock for all access to the
variable: do you have any evidence to suggest this would be a bad idea?
--
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????
news:MP************************@msnews.microsoft.c om...Ryan Liu <ad********@online.sh.cnwrote:If I have many threads write to a variable(e.g. var++) and another
thread
read it on an interval base.
For those writing thread, I know I need lock, or its value could be
lower
( even I think it is mostly not going to happen for ++ operation since
it is
not something like read a value and wait sometime then write back in
multiple threading environment, BTW, is this understanding right?).
My question, for the reading thread, do I need lock?
Yes, if you want to make sure you see a recent value.
If a lock is still a must, what about when I can accept race condition,
just the read value don''t to be "too old", e.g. 2 or more less than the
its
current value. And new read should never less then old read.
Within one thread, I don''t *think* you should ever see one value
followed by a smaller one. Within multiple threads you could.
If I don''t use lock in read thread, do I have to use volatile for the
var,
otherwise it has the potential not to read the current value?
Using volatile would mean you wouldn''t need to lock the reading thread.
An alternative is to use Thread.MemoryBarrier().
However, I''d suggest just using the lock for all access to the
variable: do you have any evidence to suggest this would be a bad idea?
Actually, no. I just though lock might more costly than volatile. This is a
client/server appliction, I am expect one day to support 500
clients(threads) at the same time.
Thanks, Jon!
Ryan
--
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
这篇关于需要读锁吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
