由于多线程语义，这是不可靠的。 [英] Because of multithreading semantics, this is not reliable.
问题描述
由于多线程语义，这是不可靠的。这个
的句子可以在Python文档中找到7.8.1 Queue
Objects。
这让我很害怕！为什么Queue.qsize（），Queue.empty（）和一个
Queue.full（）不可靠？
查看源代码Queue.py中，所有3个调用都使用互斥锁（在thread.allocate_lock（）上基于
）。这是否意味着
thread.allocate_lock（）机制不可靠（确实可怕）或者/ b $ b这与其他实现细节有关吗？
<非常感谢你解释这个谜。
奥拉夫
< blockquote>在2006-05-03， Ol********@gmail.com < Ol********@gmail.com>写道：
由于多线程语义，这是不可靠的。
这句话可以在Python文档中找到7.8.1
队列对象。
这吓到我了！为什么Queue.qsize（），Queue.empty（）和一个
Queue.full（）不可靠？
IIRC从上一次出现这个问题开始，文件
的意思是不可靠。是你得到的结果是准确的
在电话会议期间（电话在里面的时间是
互斥保护区域），但保存的结果未来某些时候可能不会因为某些其他线程
在队列中进行了操作。
我认为不可靠。短语完全错了：IMO
来电_are_可靠：他们总是在通话时返回正确的价值
（对于我之前的定义
在拨打电话时"）。这是可靠的在我的书中。
我不知道为什么有人会期望Queue.qsize（）以
返回队列的大小，因为它是将来会有一些未确定的点。
如果我们使用不可靠的话。在队列文档中使用的语义，几乎所有东西都是不可靠的。在一个
多线程环境中。例如，将全局名称
绑定到对象是不可靠的。在多线程环境中
，因为另一个线程可以稍后将其重新绑定到另一个
对象。我认为将该问题描述为全局名称
绑定在多线程环境中不可靠。是
非常误导。
查看Queue.py的源代码，所有3个调用都使用
互斥（基于thread.allocate_lock（））。这是否意味着thread.allocate_lock（）机制不可靠（确实可怕）或者这与其他实现
细节有关吗？
IMO，它与糟糕的语言选择有关。
非常感谢您解释这个谜。
没问题。
-
格兰特爱德华兹格兰特哇！ PED先生和夫人，我可以借用RAYON的26.7％
visi.com TEXTILE生产的印度尼西亚群岛吗？ />
[Ol ******** @ gmail.com]由于多线程语义，这是不可靠的。这个
句子可以在7.8.1队列
对象的Python文档中找到。
这让我很害怕！为什么Queue.qsize（），Queue.empty（）和一个
Queue.full（）不可靠？
因为他们可能在_caller_
试图使用结果的瞬间说不出真相。我不知道为什么，但人们写代码如
if q.empty（）：
return
在一个帖子中，然后抱怨这是一个错误如果其他一些线程
的他们碰巧潜入并添加另一个项目到队列
_between_时间q.empty（）正确确定q为空，
和代码为if q.empty（）生成的时间测试结果。
没有互斥锁可以阻止其他线程在这些
次之间运行。文档可以更加清楚，并且不可靠。在早期版本的Python中有一个更强的意思
。
查看Queue.py的源代码，所有3个调用都使用互斥锁（基于线程的
） .allocate_lock（））。这是否意味着
thread.allocate_lock（）机制不可靠（确实可怕）
No.
或者这是否必须要做还有其他实现细节吗？
它只与线程的工作方式有关，并且试图让b $ b消除了有缺陷的共同信念的新手。吓唬新手远离这些方法是好事，因为他们不会做新手通常认为他们做的事情。这使他们处于有吸引力的滋扰之中。许多人的类别。
蒂姆和格兰特
if q.empty（）：
return
当然你的解释是理解并且理想情况下应该包含
作为Python文档中的注释。并且不可靠应该从文档中删除
！
无论如何，非常感谢您的解释（我觉得现在更安全）。
Olaf
Because of multithreading semantics, this is not reliable. This
sentence is found in the Python documentation for "7.8.1 Queue
Objects".
This scares me! Why would Queue.qsize(), Queue.empty( ), and a
Queue.full() not be reliable?
Looking at the source code of Queue.py, all 3 calls use a mutex (based
on thread.allocate_lock()). Does this mean that the
thread.allocate_lock() mechanism is not reliable (scary indeed) or does
this have to do with other implementation details?
Many thanks for explaining this mystery.
Olaf
On 2006-05-03, Ol********@gmail.com <Ol********@gmail.com> wrote:
Because of multithreading semantics, this is not reliable.
This sentence is found in the Python documentation for "7.8.1
Queue Objects".
This scares me! Why would Queue.qsize(), Queue.empty( ), and a
Queue.full() not be reliable?
IIRC from the last time this question came up, what the doc
means by "not reliable" is that the result you get is accurate
at the time of the call (for the period the call is inside in
the mutex-protected region), but the saved result may not be
correct at some point in the future because some other thread
may have done an operation on the queue.
I''ve argued that the "not reliable" phrase is simply wrong: IMO
the calls _are_ reliable: they always return the correct value
at the time the call was made (for my previous definition of
"at the time the call was made"). That''s "reliable" in my book.
I''ve no idea why anybody would ever expect Queue.qsize() to
return the size of the queue as it was going to be at some
undetermined point in the future.
If we were to use the "not reliable" semantics that are used in
the Queue docs, pretty much everything is "not reliable" in a
multi-threading environment. For example binding a global name
to an object is "not reliable" in a multi-threaded environment
because another thread can re-bind it later to a different
object. I think describing that problem as "global name
binding is not reliable in a multi-threaded environment" is
very misleading.
Looking at the source code of Queue.py, all 3 calls use a
mutex (based on thread.allocate_lock()). Does this mean that
the thread.allocate_lock() mechanism is not reliable (scary
indeed) or does this have to do with other implementation
details?
IMO, it has to do with a poor choice of language.
Many thanks for explaining this mystery.
No problem.
--
Grant Edwards grante Yow! Mr and Mrs PED, can I
at borrow 26.7% of the RAYON
visi.com TEXTILE production of the
INDONESIAN archipelago?
[Ol********@gmail.com]Because of multithreading semantics, this is not reliable. This
sentence is found in the Python documentation for "7.8.1 Queue
Objects".
This scares me! Why would Queue.qsize(), Queue.empty( ), and a
Queue.full() not be reliable?
Because they may not be telling the truth at the instant the _caller_
tries to use the result. I''m not sure why, but people write code like
if q.empty():
return
in a thread, and then complain that "it''s a bug" if some other thread
of theirs happens to sneak in and add another item to the queue
_between_ the time q.empty() correctly determined that q was empty,
and the time the code generated for "if q.empty()" tests the result.
There''s no mutex to stop other threads from running between those
times. The docs could be clearer about this, and "not reliable" had a
stronger meaning in earlier versions of Python.
Looking at the source code of Queue.py, all 3 calls use a mutex (based
on thread.allocate_lock()). Does this mean that the
thread.allocate_lock() mechanism is not reliable (scary indeed)
No.
or does this have to do with other implementation details?
It just has to do with the way threads work, and with trying to
disabuse newbies of faulty common beliefs. It''s good to scare
threading newbies away from these methods, because they _don''t_ do
what newbies typically assume they do. That puts them in the
"attractive nuisance" category for many people.
Tim and Grant
if q.empty():
return
Of course you explanation is understood and ideally should be included
as a note in the Python documentation. And the "not reliable" should
be removed from the documentation!
Anyway, many thanks for your explanations (I feel "safer" now).
Olaf
这篇关于由于多线程语义，这是不可靠的。的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
