On May 31, 9:12 pm, "Adam Olsen" <[EMAIL PROTECTED]> wrote:
> It seems to be a commonly held belief that basic dict operations (get,
> set, del) are atomic.
They are atomic so long as the key does not have a custom __hash__,
__eq__, or __cmp__ method which can trigger arbitrary Python code.
With
On Jun 1, 3:51 am, Duncan Booth <[EMAIL PROTECTED]> wrote:
> "Adam Olsen" <[EMAIL PROTECTED]> wrote:
> > So there you have it: if you're using a dict with custom classes (or
> > anything other than str) across multiple threads, and without locking
> > it, it's possible (though presumably extremely
On 6/1/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > So there you have it: if you're using a dict with custom classes (or
> > anything other than str) across multiple threads, and without locking
> > it, it's possible (though presumably extremely rare) for a lookup to
> > fail even through t
"Adam Olsen" <[EMAIL PROTECTED]> wrote:
> So there you have it: if you're using a dict with custom classes (or
> anything other than str) across multiple threads, and without locking
> it, it's possible (though presumably extremely rare) for a lookup to
> fail even through the key was there the en
> So there you have it: if you're using a dict with custom classes (or
> anything other than str) across multiple threads, and without locking
> it, it's possible (though presumably extremely rare) for a lookup to
> fail even through the key was there the entire time.
That could be fixed by adding
It seems to be a commonly held belief that basic dict operations (get,
set, del) are atomic. However, since I know searching the hash table
is a multistep process, I thought I'd check it out for sure.
First, my assumption is that one thread is attempting to get a single
key, while other threads a
