In article <[EMAIL PROTECTED]>,
catsup <[EMAIL PROTECTED]> wrote:
>
>It was actually quite a minor adjustment in the application to follow
>the oft repeated advice here on this subject to share only the
>Queue object between threads. Making the update of the dictionary
>just another queued command
It was actually quite a minor adjustment in the application to follow
the oft repeated advice here on this subject to share only the Queue
object between threads. Making the update of the dictionary just
another queued command request caused both the dictionary read and
write to be performed by th
In article <[EMAIL PROTECTED]>,
catsup <[EMAIL PROTECTED]> wrote:
>
>I have an app written under version Python 2.3.5. The problem I'm
>having is that it hangs on one of its threads. The thread that hangs
>does updates to a standard dictionary shared with another thread that
>only reads this dict
Donn Cave wrote:
> In article <[EMAIL PROTECTED]>,
> Steve Holden <[EMAIL PROTECTED]> wrote:
> ...
>
>>I don't see why you should get problems on SMP hardware, since the
>>threads are all part of the same process and should therefore (I'd have
>>thought) be tagged with the same processor affini
Yes. The test for Empty was edited out. There is a great deal going
on in this application, most not germane to the problem. I should
perhaps let all of you be the judge of that. Hopefully, this will be
enough to help generate ideas.
Thanks,
Randy
--
http://mail.python.org/mailman/listinfo/p
catsup wrote:
> The accessing thread takes command requests off a queue, every
> half-second, placed there by an altogether different thread, and does a
> lookup on this same dictionary before performing this command:
>
>def run_thread(self):
> while( not self.terminate ):
> cm
Yes. Iterating over a list that you concurrently update will
definately cause problems. That is not the type of "read" I am doing
in the application. My read is one key/value translation. Below is an
example of the operations I am performing to help clarify.
The update thread, running once eve
In situations like this, you need to guard the resource with a mutex.
In Python, things like insertions are atomic but iterations are not.
Thusly, if you wrap it with a mutex, things can be made safe. I saw,
"can be", because you then have to ensure you always use the mutex to
satify your concurre
In article <[EMAIL PROTECTED]>,
Steve Holden <[EMAIL PROTECTED]> wrote:
...
> I don't see why you should get problems on SMP hardware, since the
> threads are all part of the same process and should therefore (I'd have
> thought) be tagged with the same processor affinity. Hence the GIL
> shoul
Steve Holden <[EMAIL PROTECTED]> writes:
> catsup wrote:
>> Hi,
>> I have an app written under version Python 2.3.5. The problem I'm
>> having is that it hangs on one of its threads. The thread that hangs
>> does updates to a standard dictionary shared with another thread that
>> only reads this
catsup wrote:
> Hi,
>
> I have an app written under version Python 2.3.5. The problem I'm
> having is that it hangs on one of its threads. The thread that hangs
> does updates to a standard dictionary shared with another thread that
> only reads this dictionary. This app works beautifully on a
Hi,
I have an app written under version Python 2.3.5. The problem I'm
having is that it hangs on one of its threads. The thread that hangs
does updates to a standard dictionary shared with another thread that
only reads this dictionary. This app works beautifully on a single
processor boxes in
12 matches
Mail list logo
