locks

[Cliff Wells]

On Wed, 2004-10-13 at 14:03 +0000, Duncan Booth wrote:
> Cliff Wells wrote:
> 
> > I'm no expert at dis nor Python bytecode, but I'll give it a shot :)
> > 
> >>>> l = []
> >>>> dis.dis(l.append(1))
> > 134           0 LOAD_GLOBAL              0 (findlabels)
> >               3 LOAD_FAST                0 (code)
> >               6 CALL_FUNCTION            1
> >               9 STORE_FAST               5 (labels)
> >  
> > 
> > ... 
> ><snip dis spitting out over 500 lines of bytecode>
> > ...
> >  
> > 172     >>  503 PRINT_NEWLINE
> >             504 JUMP_ABSOLUTE           33
> >         >>  507 POP_TOP
> >             508 POP_BLOCK
> >         >>  509 LOAD_CONST               0 (None)
> >             512 RETURN_VALUE
> >>>>
> > 
> > 
> > It looks fairly non-atomic to me. 
> 
> The append method of a list returns None. dis.dis(None) disassembles the 
> code from the last traceback object, nothing at all to do with your 
> l.append(1) code.

Ah, thanks.  I thought 500+ lines of bytecode was a bit excessive for a
simple append(), but didn't see any reason why.  I saw the comment in
the docs about dis returning the last traceback if no argument was
provided but didn't see how that applied here. 

> 
> Try this instead:
> 
> >>> def f():
> 	l.append(1)
> 
> 	
> >>> dis.dis(f)
>   2           0 LOAD_GLOBAL              0 (l)
>               3 LOAD_ATTR                1 (append)
>               6 LOAD_CONST               1 (1)
>               9 CALL_FUNCTION            1
>              12 POP_TOP             
>              13 LOAD_CONST               0 (None)
>              16 RETURN_VALUE    

Much more reasonable.  Still, I think my argument stands since this
appears non-atomic as well, although I do note this:

>>> l = []
>>> dis.dis(l.append)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/dis.py", line 46, in dis
    raise TypeError, \
TypeError: don't know how to disassemble builtin_function_or_method
objects
>>>

This suddenly gave me a smack on the head that list.append is
undoubtedly written in C and might, in fact, retain the GIL for the
duration of the function in which case the operation might, in fact, be
atomic (yes, I know that isn't necessarily what the above traceback was
saying, but it served as a clue-stick).

Still, despite the probability of being quite mistaken about the low-
level internals of the operation, I still stand by my assertion that not
using locks for mutable data is ill-advised at best, for the reasons I
outlined in my previous post (aside from the poorly executed
disassembly).

Regards,
Cliff

-- 
Cliff Wells <clifford.wells at comcast.net>