Why are my Python second counting Threads unable to work side by side?
Hi
I asked another python threading question, but this one may explain my issue..
I wrote this code, to see if two second counting threads could work at the same time.
For some reason, only one does the counting.
This is symptomatic of my problems with Python Threads
Why does this code only count one of the instances, and not the 2nd
I always get one Thread that is blocked from execution!
Thank You
I asked another python threading question, but this one may explain my issue..
I wrote this code, to see if two second counting threads could work at the same time.
For some reason, only one does the counting.
This is symptomatic of my problems with Python Threads
Why does this code only count one of the instances, and not the 2nd
I always get one Thread that is blocked from execution!
import threading,time
class counter:
def __init__(self,thread_number) :
self.thread_number = thread_number
t = threading.Thread(target=self.count())
t.start()
def count(self):
frameCount = 0
while True:
print (self.thread_number,' frame #',frameCount)
frameCount += 1
time.sleep(1)
counter(1)
counter(2)Thank You
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The main issue were the parenthesis in the target=self.count()
separating creation and starting threads gives you more control in some situations.
It's not necessary, but can allow you to have a different order for object creation and object startup.
and to have object data available before the thread is necessarily started.
You're also closer to the behavior of any object, that's derived from the class Thread.
For example you could rewrite the the class of my previous first code snippet code following way and it would still have the same behaviour:
if you subclass from threading.Thread and overload __init__() for initialization and run() for the actual thread code, then it would behave
identical to my previously proposed suggestion.
So more control with the separation of creation and start and more similar to existing threading.Thread objects.
separating creation and starting threads gives you more control in some situations.
It's not necessary, but can allow you to have a different order for object creation and object startup.
and to have object data available before the thread is necessarily started.
You're also closer to the behavior of any object, that's derived from the class Thread.
For example you could rewrite the the class of my previous first code snippet code following way and it would still have the same behaviour:
class counter(threading.Thread):
def __init__(self, thread_number):
super().__init__()
self.thread_number = thread_number
def run(self):
frameCount = 0
while True:
print (self.thread_number,' frame #',frameCount)
frameCount += 1
time.sleep(1)if you subclass from threading.Thread and overload __init__() for initialization and run() for the actual thread code, then it would behave
identical to my previously proposed suggestion.
So more control with the separation of creation and start and more similar to existing threading.Thread objects.
just edited my previous post by adding an example of subclassing threading.Thread.
As I saw, that you endorsed my answer already and I'm not sure, my answer was complete at the time of the endorsement. Thus this comment to be sure our actions didn't overlap.
As I saw, that you endorsed my answer already and I'm not sure, my answer was complete at the time of the endorsement. Thus this comment to be sure our actions didn't overlap.
ASKER
So simple. Makes Sense!
Why does it matter if I don't call it after it's constructed, the last line of the ctr? Does it need time for some fresh air first? I think I had a bad habit in Java of starting Threads in their own constructors.
Thanks