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. -- Peter Hansen, P.Eng. Engenuity Corporation 416-617-1499 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
