Re: Bad practice with an MFC thread? How can I improve it?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

See below...
On Thu, 17 Apr 2008 14:56:04 +0100, "Moschops" <moschops@xxxxxxxxxxxxxxxxxxxxx> wrote:

I've had to alter some code I was handed. A live camera was constantly
filling a ring buffer with images, and on a given signal (which I've put in
as a button push for the moment) it stopped, leaving the last X images in
the buffer. The requirement came in such that it would run for X/2 more
frames after the button was pushed (i.e. when you push the button, the saved
video sequence is centred at the time of pushing the button).

Initially, I added a frame counter after the button was pushed, but found
that it caused the processor to spend all the time on counting and no more
time on updating the frames, so in essence it hung. Ideal time for threads,
I decided.

So now pushing the button calls an AfxBeginThread function, like this:

// Spawn thread to decide when to stop capturing
CWinThread* pStopCaptureThread;
pStopCaptureThread = AfxBeginThread (
fnStopCaptureThread,this,THREAD_PRIORITY_NORMAL,0,0,NULL);

Now, I understand that the fnStopCaptureThread function cannot be part of
the class within which this is all happening,
****
That is ABSOLUTELY not true!!!! I typically make it a class member. Key here is that it
must be a 'static' class member.
*****
so it's a global function.
*****
A global function is so retro.

See my essay on worker threads. If you need to access members of the class, the typical
technique is as you have none, passing 'this' as the thread parameter
****
However, I still need access to various class variables to do my
calculations, so that global function simply calls another function within
the original class object; the fnStopCaptureThread knows what object called
it because it is passed a 'this'.

Here's the body of that global function:

UINT fnStopCaptureThread(LPVOID lParam)
****
What are those noise characters 'fn' at the start? If this made sense, EVERY function
would have to start with 'fn', and that is not common practice. But make it a static
member of your class!
****
{
// Run the stopcapture code
Sequencer_class* dlg2 = (Sequencer_class*)lParam; // This kind of casting
is not the C++ way. Needs fixing. Moschops.
dlg2->StopCapture();
****
Yes, this is the standard technique.
****
return 0;
}

StopCapture is the function, within the class, that handles counting frames
and working out when to stop. This all seems happy now, and it behaves as
expected thus far.

Looking at my code, I am aware that I've now got a thread playing with my
class object, and the code that spawned that thread is also still playing
with the exact same object, albeit never calling the StopCapture function.
I'm got this feeling that it's a bad idea to have in essence two threads
accessing the same object - presumably I won't be able to predict when
they'll do things relative to each other and could end up with problems.
****
Nobody cares if you are playing with the "same object" and in fact that is largely
irrelevant. What IS relevant is that you must not play with the same DATA in that object.
So if you are manipulating the same data values from both threads, you are going to be in
trouble. Don't do it without synchronization. Better still, don't do it at all.
****

This code section is quite simple and the variables StopCapture() is playing
with aren't touched by anything else until the thread is killed, but
nonetheless is seems like bad practice.
*****
Multithreading only cares about individual memory locations being accessed concurrently.
Nobody actually cares what syntax is used to create those locations. If the locations are
not accessed concurrently by two or more threads, there is no issue of practice involved
at all, because the values are independent.
****
My MFC experience is quite limited
(I'm usually an embedded coder) so I'm not sure if I'm seeing things, or if
this is a bad idea. Can anyone help me out? Is this bad practice, and if so,
what's a better way to do it?
****
The proper way to handle this depends a lot on what you are manipulating and how you are
manipulating it, and at what frequency (high bandwidth vs. low bandwidth), how large the
data is that needs concurrent access, and a lot of other parameters. Without detailed
knowledge of what is going on, there is no one answer that can solve your problem.
joe
*****

'Chops

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Melody (a second class citizen?)
    ... perceive in every aspect of my playing. ... Folk melodies often seem to be ... to practice that free heart-to-fingers playing as it is to practice ... Criss Cross jazz label. ...
    (rec.music.makers.guitar.jazz)
  • Re: Melody (a second class citizen?)
    ... perceive in every aspect of my playing. ... is based on an old Irish folk melody. ... Folk melodies often seem to be ... to practice that free heart-to-fingers playing as it is to practice ...
    (rec.music.makers.guitar.jazz)
  • Re: practice strategy with limited time
    ... I'm sure - have limited time to practice. ... to other tunes. ... That means playing intros, keeping solid time, ... it turns into solo guitar which I don't really care for. ...
    (rec.music.makers.guitar.jazz)
  • Re: Soloing with non-stop 8th notes - important?
    ... Playing with wit and intellegence is ... No analogy is perfect. ... takes to be an improvising comedian. ... my believe is that one should practice what they want to ...
    (rec.music.makers.guitar.jazz)
  • Re: Bad practice with an MFC thread? How can I improve it?
    ... StopCapture is the function, within the class, that handles counting ... every other user control ceases taking input when the ... nonetheless is seems like bad practice. ... camera input. ...
    (microsoft.public.vc.mfc)