On 12/12/2012 12:29 PM, Dave Angel wrote:
On 12/12/2012 03:11 PM, Wanderer wrote:
I have a program that has a main GUI and a camera. In the main GUI,
you can manipulate the images taken by the camera. You can also use
the menu to check the camera's settings. Images are taken by the
camera in a separate thread, so the long exposures don't block the
GUI. I block conflicts between the camera snapshot thread and the
main thread by setting a flag called self.cameraActive. I check to
see if the cameraActive flag is false and set the cameraActive to
True just before starting the thread. I generate an event on exiting
the thread which sets the cameraActive flag to False. I also check
and set and reset the flag in all the menu commands that access the
camera. Like this.
def onProperties(self, event):
""" Display a message window with the camera properties
event -- The camera properties menu event
"""
# Update the temperature
if not self.cameraActive:
self.cameraActive = True
self.camera.getTemperature()
camDict = self.camera.getPropertyDict()
self.cameraActive = False
else:
camDict = {'Error': 'Camera Busy'}
dictMessage(camDict, 'Camera Properties')
This works
I don't think so. in between the if and the assignment, another thread
could get in there and also set the flag. Then when either one of them
finishes, it'll clear the flag and the other code is unprotected.
For semaphores between multiple threads, you either have to define only
a single thread at any given moment being permitted to modify it, or you
have to use lower-level primitives, sometimes called test+set operation.
i don't know the "right" way to do this in Python, but this isn't it.
but my question is, is there a better way using semaphores, locks or
something else to prevent collisions between threads?
Thanks
if you already have the cameraActive variable reset by an event at
thread termination; it's not necessary to set it false in the menu
command. It's better NOT to do that. Your GUI menu functions need only
test to see if self.cameraActive is false, and then set it to true just
before the launch of the second thread. The second thread, itself,
ought never change the cameraActive variable.
I'm also not sure why you are able to obtain the information from the
camera sequentially (camDict?) when you say you are not blocking the GUI.
I assume self.camera.getTemperature() launches the second thread ? Is it,
somehow, explicitly allowing the continued processing of GUI events that
accessing the camera straight in the GUI would not allow?
If you are talking about the Python semaphore library, I don't think you
need it.
Semaphores are really for use when multiple threads wish to access a
resource where more than one thread can use the resource at a time;
That would mean multiple threads using the camera at once... not a good
idea.
The Lock() object essentially does the same thing, but assumes only 1
thread may use it at a time; hence that would be sufficient (if it
were needed at all!).
A lock is in the "thread" library (Python 2.xx) or the "threading"
library (Python 3.xx). Semaphores aren't part of the thread library in
Python 2.xx... (another reason not to bother with them...)
However, Locking will cause the GUI thread to block when the camera is
in use, which isn't what you want -- correct?
There is a way to test the lock but not block, which is equivalent to
your variable (to be honest!); I'm pretty sure that Python doesn't use
true Posix threads but only the GNU Pth library. That means that the
only time threads truly switch is determined by the Python interpreter.
In that case, all python variable assignments are going to be effectively
atomic anyhow... and a variable, like you are using, is identical to a lock.
(Atomic merely means the write can't be interrupted by a thread switch partway
through).
If you have a multi-processing environment, there is a multiprocessor
library -- where the lock or semaphore mechanism would be important.
But I really don't think you need it.
--
http://mail.python.org/mailman/listinfo/python-list
