On Fri, Mar 6, 2009 at 7:28 AM, Peter Hansen <[email protected]> wrote: > > Kamil Gorlo wrote: >> On Thu, Mar 5, 2009 at 3:46 AM, Philip Jenvey <[email protected]> wrote: >>> http://effbot.org/pyfaq/what-kinds-of-global-value-mutation-are-thread-safe.htm >>> >> Yeah, this site is a bit ambigous, e.g. >> >> "Operations that replace other objects may invoke those other objects’ >> __del__ method when their reference count reaches zero, and that can >> affect things. This is especially true for the mass updates to >> dictionaries and lists. When in doubt, use a mutex!" >> >> But before that statement author said that following operations are atomic: >> >> D[x] = y >> D1.update(D2) >> >> where x,y are objects and D1 and D2 are dict. So how this could be true? > > I believe the adjective "atomic" applies only to the affect on D or D1, > in this case, and given the comment about __del__ I think it probably > doesn't apply even to the .update() case (unless D2 has length 1). > >> But even if we assume that getitem and setitem on dict are atomic (on >> 'steady' value only? which means primitives?). How to solve problem >> which I am facing now: >> >> I want to start another thread T1 in my Pylons App (manually, not >> Paste#http worker) and have some global dict which all http workers >> will read. But T1 periodically will update this dictionary (in fact >> all he want to do is to swap this global dict with local dict which >> was prepared during his work). In this dict I will have Python >> primitives (other dicts too) and simple classes which act only as >> 'structs'. Do I need lock? > > If by "swap" you simply mean you will be rebinding the global name to a > new dictionary, then the rebinding itself will certainly be atomic. One > the other hand, if the various worker threads access this global name > more than once in a request (or session, or whatever) then you will > certainly have problems as they would use the old dictionary for part of > the request then use the new one. > > If they simply grab a local reference to the global name (possibly > storing it in their request object, or session, depending on what you > need) when first needed, and thereafter access it only from there, I > can't see how you'd have any problems (ignoring issues involving changes > to various contained items, which might be shared if you haven't ensured > they are not). > > I think if you aren't sure yet what will work, post some pseudo-code > showing what you would do if you were to ignore thread-safety issues. > > Also note that use of the Queue module is a very common step to dealing > with thread-safety issues, generally resulting in most or all potential > problems just going away. If that could work for you it's probably the > best bet.
I concur, in fact I wrote an article advocating just that :) http://www.ibm.com/developerworks/aix/library/au-threadingpython/ > > -- > Peter Hansen, P.Eng. > Engenuity Corporation > 416-617-1499 > > > > -- Cheers, Noah --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
