Есть ли некоторые случаи, где потоки Python могут безопасно управлять общим состоянием?

Некоторое обсуждение в другом вопросе призвало меня к лучше понять случаи, где блокировка требуется в многопоточных программах Python.

На эту статью о поточной обработке в Python у меня есть несколько твердых, тестируемых примеров ловушек, которые могут произойти когда несколько общих состояний доступа потоков. Состояние состязания в качестве примера, обеспеченное на этой странице, включает гонки между чтением потоков и управлением совместно используемой переменной, сохраненной в словаре. Я думаю, что случай для гонки здесь является очень очевидным, и к счастью является чрезвычайно тестируемым.

Однако я не мог вызвать состояние состязания с атомарными операциями, такими как список, добавляет или переменные инкременты. Этот тест исчерпывающе пытается продемонстрировать такую гонку:

from threading import Thread, Lock
import operator

def contains_all_ints(l, n):
    l.sort()
    for i in xrange(0, n):
        if l[i] != i:
            return False
    return True

def test(ntests):
    results = []
    threads = []
    def lockless_append(i):
        results.append(i)
    for i in xrange(0, ntests):
        threads.append(Thread(target=lockless_append, args=(i,)))
        threads[i].start()
    for i in xrange(0, ntests):
        threads[i].join()
    if len(results) != ntests or not contains_all_ints(results, ntests):
        return False
    else:
        return True

for i in range(0,100):
    if test(100000):
        print "OK", i
    else:
        print "appending to a list without locks *is* unsafe"
        exit()

Я запустил тест выше без отказа (100x 100k многопоточный, добавляет). Кто-либо может заставить это перестать работать? Есть ли другой класс объекта, который может быть сделан неправильно себя вести через атомарный, возрастающее, модификацию потоками?

Они неявно 'атомарная' семантика относятся к другим операциям в Python? Разве это непосредственно связано с GIL?