Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #31058 > unrolled thread

an error in python lib?

Back to article view | Back to comp.lang.python

Contents

  an error in python lib? Wenhua Zhao <whzhao@gmail.com> - 2012-10-09 17:32 -0700
    Re: an error in python lib? Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-10-10 14:04 +0200

#31058 — an error in python lib?

Hi list,

I just noticed that in /usr/lib/python2.7/threading.py

class _Condition(_Verbose):
    ...
    def _is_owned(self):
        # Return True if lock is owned by current_thread.
        # This method is called only if __lock doesn't have
_is_owned().
        if self.__lock.acquire(0):
            self.__lock.release()
            return False
        else:
            return True

The return values seem to be wrong.  They should be swapped:

    def _is_owned(self):
        if self.__lock.acquire(0):
            self.__lock.release()
            return True
        else:
            return False

Or I understood it wrong here?

Thanks,
Wenhua

[toc] | [next] | [standalone]

#31075

Am 10.10.2012 02:32, schrieb Wenhua Zhao:
> I just noticed that in /usr/lib/python2.7/threading.py
>
> class _Condition(_Verbose):
>      ...
>      def _is_owned(self):
>          # Return True if lock is owned by current_thread.
>          # This method is called only if __lock doesn't have
>          # _is_owned().
>          if self.__lock.acquire(0):
>              self.__lock.release()
>              return False
>          else:
>              return True
>
> The return values seem to be wrong.  They should be swapped:
>
>      def _is_owned(self):
>          if self.__lock.acquire(0):
>              self.__lock.release()
>              return True
>          else:
>              return False
>
> Or I understood it wrong here?

I think you are correct, but there is one thing that I would audit 
first: The whole code there seems to use integers in places where a 
boolean would be appropriate, like e.g. the 'blocking' parameter to 
acquire(). I wouldn't be surprised to find the interpretation of "0 
means no error" in some places there, so that a False translates to 0 
and then to "OK, I have the lock".

Also, assuming an underlying implementation where a nonblocking 
acquire() could still newly acquire an uncontended lock, that 
implementation would release the acquired lock and still return "yes I'm 
holding the lock", which would be dead wrong. It must verify if the lock 
count is at least 2 after acquiring the lock.

Uli

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web