Threading - Why Not Lock Objects Rather than lock the interpreter

Discussion in 'Python' started by Fuzzyman, Dec 5, 2003.

  1. Fuzzyman

    Fuzzyman Guest

    Looking at threading code it seems that the Global Interpreter Lock is
    a bit of a 'brute force' way of preventing two threads attempting to
    access sensitive objects simultaneously....

    Why not have a new type of object with a 'lock' facility... if an
    object is locked then any thread trying to access the object other
    than the one obtaining the lock is blocked until the lock is
    released..... rather than blocking *all* threads until one thread has
    finished with the object.....

    It could be implemented as a new attribute of existing objects... or
    new types of objects.....

    Fuzzy
    Fuzzyman, Dec 5, 2003
    #1
    1. Advertising

  2. Re: Threading - Why Not Lock Objects Rather than lock theinterpreter

    (Fuzzyman) writes:

    > Looking at threading code it seems that the Global Interpreter Lock is
    > a bit of a 'brute force' way of preventing two threads attempting to
    > access sensitive objects simultaneously....
    >
    > Why not have a new type of object with a 'lock' facility... if an
    > object is locked then any thread trying to access the object other
    > than the one obtaining the lock is blocked until the lock is
    > released..... rather than blocking *all* threads until one thread has
    > finished with the object.....
    >
    > It could be implemented as a new attribute of existing objects... or
    > new types of objects.....


    It would slow down the interpreter drastically. The important thing
    here is that for the above to be true, you'ld need to define
    "sensitive objects" to be "objects with a reference count" (i.e. all
    of them). Because of that if you did this you'ld be doing about as
    much locking and unlocking as you would code execution. For example,
    calling the following function would require at least 2 lock/unlock
    pairs (there may be more, I'm not thinking too hard about it):

    def donothing(): pass

    --
    Christopher A. Craig <>
    Code that does not adhere to the documentation is bad code that should
    be broken, even if it is your own. -- Christian Tismer
    Christopher A. Craig, Dec 5, 2003
    #2
    1. Advertising

  3. Fuzzyman wrote:
    > Looking at threading code it seems that the Global Interpreter Lock is
    > a bit of a 'brute force' way of preventing two threads attempting to
    > access sensitive objects simultaneously....
    >
    > Why not have a new type of object with a 'lock' facility... if an
    > object is locked then any thread trying to access the object other
    > than the one obtaining the lock is blocked until the lock is
    > released..... rather than blocking *all* threads until one thread has
    > finished with the object.....


    Because the reference counter of objects has to be synchronized.

    Daniel
    Daniel Dittmar, Dec 5, 2003
    #3
  4. Re: Threading - Why Not Lock Objects Rather than lock theinterpreter

    On Sat, 5 Dec 2003, Christopher A. Craig wrote:

    > (Fuzzyman) writes:
    >
    > > Looking at threading code it seems that the Global Interpreter Lock is
    > > a bit of a 'brute force' way of preventing two threads attempting to
    > > access sensitive objects simultaneously....
    > >
    > > Why not have a new type of object with a 'lock' facility... if an
    > > object is locked then any thread trying to access the object other
    > > than the one obtaining the lock is blocked until the lock is
    > > released..... rather than blocking *all* threads until one thread has
    > > finished with the object.....
    > >
    > > It could be implemented as a new attribute of existing objects... or
    > > new types of objects.....

    >
    > It would slow down the interpreter drastically. The important thing
    > here is that for the above to be true, you'ld need to define
    > "sensitive objects" to be "objects with a reference count" (i.e. all
    > of them). Because of that if you did this you'ld be doing about as
    > much locking and unlocking as you would code execution. For example,
    > calling the following function would require at least 2 lock/unlock
    > pairs (there may be more, I'm not thinking too hard about it):
    >
    > def donothing(): pass


    As an example of what can happen, I played around with building a
    pre 2.3alpha CVS Python with OpenWatcom on OS/2.

    Building the Python core as a DLL resulted in a Pystone rating 25% less
    than a static linked Python.exe.

    This was traced to the OpenWatcom malloc() implementation always using
    thread locks when linked to code in a DLL, even when extra threads are
    never created (ie only the primary thread is running). Enabling PyMalloc
    fixed that.

    While Python does many malloc()s and free()s, it does many, many more
    object accesses.

    So the performance degradation from an object locking strategy can be
    savage.

    --
    Andrew I MacIntyre "These thoughts are mine alone..."
    E-mail: (pref) | Snail: PO Box 370
    (alt) | Belconnen ACT 2616
    Web: http://www.andymac.org/ | Australia
    Andrew MacIntyre, Dec 5, 2003
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?SmFzb24gQ2hhbg==?=

    why DateTime.ToString("hh:mm:ss") give 12:00:00 rather than 00:00:

    =?Utf-8?B?SmFzb24gQ2hhbg==?=, Feb 8, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    3,774
    Hans Kesting
    Feb 8, 2006
  2. Robert Brewer
    Replies:
    0
    Views:
    478
    Robert Brewer
    Dec 5, 2003
  3. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,762
    Smokey Grindel
    Dec 2, 2006
  4. Replies:
    6
    Views:
    387
    James Kanze
    Oct 16, 2007
  5. Justin
    Replies:
    4
    Views:
    164
    Ben Morrow
    Oct 30, 2003
Loading...

Share This Page