threading.RLock not subclassible?

David Bolen db3l at fitlinxx.com
Fri Feb 9 13:54:19 EST 2001


Rick Lee <rwklee at home.com> writes:

> Regarding your comment on what you think may be the unsafe and
> unpredictable code: the code does access a couple of global lists,
> the only things done with these lists are len() and append(), which
> I read somewhere are "atomic".

Perhaps, although given that any given method might behind the scenes
have been overridden with arbitrary code, I would probably suggest
never making such assumptions and instead always protecting common
data.  (And in particular when you are having uncertain behavior :-))

One point was that the code seemed to assume the object pointed to by
"me" is the same between when you append it to started and when you
later append it to completedRunObj (if the completed is supposed to
track the started), but since I think "me" may end as the same local
label accessed simultaneously by multiple threads, you could fine "me"
change in between (so perhaps you'd add "n" to the started list, but
then append "n-1" to the completed list when the new thread just
started re-evaluates the length of the runners and assigns it to "me").

Basically, with threading it's always better to play it safe when it
involves any potential for multi-thread access to the same data.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/



More information about the Python-list mailing list