clifford.wells at comcast.net
Wed Oct 13 16:19:18 CEST 2004
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():
> >>> 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 = 
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
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
Cliff Wells <clifford.wells at comcast.net>
More information about the Python-list