On Thu, Mar 5, 2009 at 7:28 PM, 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).
Yes, of course - we should consider "atomic" separately for each line.
>> 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).
Yes, that is the case. I have global variable and 'swap' means
'rebinding' to new dictionary.
So there is global dict G and two types of threads:
1. HTTP Worker (in many instances), and he does in each request:
- local_G = G
- from this moment operate only on 'local_G'
2. Refresh Worker (only one instance) and he from time to time does:
- tmp_G = {'bla' : 42, .... }
- G = tmp_G
So everything probably will be OK and this solution is thread-safe in
Python. But.. I will probably use locks even if they *might* be not
necessary - this code is also for other people than me and for them it
will be probably easier to read and understand that everything works
OK. Especially that there is probably no performance trade-off.
> 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 know this Queue pattern and I also know that it is probably the best
solution for synchronization problems not only in Python :) I was only
wondering how much we can get from Python primitives :)
However - big thanks to all of you guys for posts, I've learned
something new (as everyday :)).
Cheers,
Kamil
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
