Jack Orenstein wrote:
One thing you might try is experimenting with sys.setcheckinterval(),
just to see what effect it might have, if any.
That does seem to have an impact. At 0, the problem was completely
reproducible. At 100, I couldn't get it to occur.
If you try other values in between, can you
On my machines (one Py2.4 on WinXP, one Py2.3.4 on RH9.0) I don't
see this behaviour. Across about fifty runs each.
Thanks for trying this.
One thing you might try is experimenting with sys.setcheckinterval(),
just to see what effect it might have, if any.
That does seem to have an impact. At 0, t
Jack Orenstein wrote:
Peter Hansen wrote:
> You've got two shared global variables, "done" and "counter".
> Each of these is modified in a manner that is not thread-safe.
> I don't know if "counter" is causing trouble, but it seems
> likely that "done" is.
I understand that.
> Basically, the
module (as is
> generally recommended, instead of using "thread"), you would
> use threading.Lock().
As my note said, I did start with the threading module. And variables
updated by different threads were protected by threading.Condition
variables. As I analyzed my test cases, and threa
Jack Orenstein wrote:
I am using Python 2.2.2 on RH9, and just starting to work with Python
threads.
Is this also the first time you've worked with threads in general,
or do you have much experience with them in other situations?
This program seems to point to problems in Python thread sched
This may help.
http://linuxgazette.net/107/pai.html
Also be sure to google.
search strategy:
Python threading
Python threads
Python thread tutorial
threading.py example
Python threading example
Python thread safety
hth,
M.E.Farmer
--
http://mail.python.org/mailman/listinfo
the thread module, not threading. This program seems to
point to problems in Python thread scheduling.
The program is invoked like this:
python threadtest.py THREADS COUNT
THREADS is the number of threads created. Each thread contains a loop
that runs COUNT times, and all threads increment a
