RetroSearch Browse

Tue Aug 9 11:31:47 CEST 2011 · https://mail.python.org/pipermail/python-dev/2011-August/112764.html

Probably I want to re-invent a bicycle. I want developers to say me
why we can not remove GIL in that way:

1. Remove GIL completely with all current logick.
2. Add it's own RW-locking to all mutable objects (like list or dict)
3. Add RW-locks to every context instance
4. use RW-locks when accessing members of object instances

Only one reason, I see, not do that -- is performance of
singlethreaded applications. Why not to fix locking functions for this
4 cases to stubs when only one thread present? For atomicity, locks
may be implemented as this:
For example for this source:
--------------------------------
import threading

def x():
    i=1000
    while i:
        i--

a = threading.Thread(target=x)
b = threading.Thread(target=x)
a.start()
b.start()
a.join()
b.join()
--------------------------------
in my case it will be fully parallel, as common object is not locked
much (only global context when a.xxxx = yyyy executed). I think,
performance of such code will be higher that using GIL.

Other significant reason of not using my case, as I think, is a plenty
of atomic processor instructions in each thread, which affect kernel
performance.

Also, I know about incompatibility my variant with existing code.

In a summary: Please say clearly why, actually, my variant is not
still implemented.

Thanks.

-- 
Segmentation fault

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2011-August/112764.html below:

[Python-Dev] GIL removal question