Re: Thread Problems

See below...
On Sun, 24 Feb 2008 16:44:36 -0800, "Roger Rabbit" <roger@xxxxxxxxxx> wrote:

Eventually the paint routine will become complicated. The idea I have is to
use a flag in the thread to be checked and if its an abort flag then the
draw thread can bail.
****
Define "complicated". There are lots of ways to optimize drawing that doesn't involve
threading as a solution. Not that threading is bad as such, but you need to consider that
there are often better alternatives.
****

Putting the about box on a thread comes from the idea of using a dialog box
to display progress from say a computationally demanding process that is
running in the main thread or threads.

I posted a simple routine to better learn the calls needed rather than post
200,000 lines of code to sift through.
****
Learning the calls by choosing bad ideas doesn't help learn the calls. It merely adds
confusion caused by using bad ideas, such as user-visible objects in threads whose parents
are in a different thread.
****

While sifting through MSDN I found a reference for an pfnThreadProc that's
used to pass the parameter to the child process such as the window handle in
the example I posted. So I will have to use that vehicle to pass my
parameter(s) to AfxBeginThread to launch a child process.
****
Do you mean "worker thread" instead of "child process"? Yes, the parameter to
AfxBeginThread (I have no idea what a pfnThreadProc is, since you gave no context) is used
to pass parameters to the thread. The question is, what parameter do youwant to pass? The
window handle is generally a poor choice a lot of the time. Only in a few limited
contexts does it give any advantage over passing a CWnd*.
****

Once I have the modules I need built, then I can reuse them in a more
practical project than the trivial code I posted. The problem is that the
standard C++ libraries are not thread aware.
****
I have no idea what you mean by this. Do you mean std::? Yes, none of these are
thread-aware, but that's why you have synchronization primitives lie CRITICAL_SECTION.
More importantly, try to avoid *needing* synchronization. So the question is: why
construct a system in which you need to provide for synchronization? Why not avoid it
entirely by creating a system that doesn't need synchronization at all? (See my essay:
The Best Synchronization is No Synchronization)
****

I already have a working mutex class so dealing with the need to lock a
thread to avoid problems is already available.
****
OK, is there a justification for using a mutex instead of a CRITICAL_SECTION? What,
precisely, does this class do that requires a separate class to handle it, as opposed to
just calling EnterCriticalSection? (there *are* correct answers to this question, by the
way). Generally, synchronization is either so simple you don't need a class, or so
complicated that a class doesn't solve anything.
****

I am also working on some ideas of implementing a singleton class but this
is not as easy to do in a threaded environment.
****
Depends on what it is supposed to do. Note a singleton class should be trivial in a
mulithreaded environment, no harder than a simple variable.
joe
****

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:p56ur3h2lub440e1d9q287e9taen25l0fe@xxxxxxxxxx
Well, unless you have an *amazingly* complex picture to draw, this is
probably a bad place
to use a thread.

Playing with thread priorities is a guaranteed way to get into trouble
nearly all the
time; it makes sense in some very restricted contexts, but you should make
sure you are on
a multiprocessor before trying to play games with thread priority.

The paint routine is a poor choice for learning threading.

You should not bring up user-visible objects in a secondary thread.
Putting the About box
in a separate thread would be a very poor strategy for program
development.

If you are looking for learning exercises for threading, interesting ideas
deal with I/O
devices with unbounded blocking times (for example, serial ports), or
situations in which
concurrency actually buys something (handling many queries at one time,
each one of which
takes a lot of computation).

Painting is a poor choice in general, and take as given that it is a
fundamentally Bad
Idea to put user-visible windows in any but the main GUI thread, and work
from there.

Threading is very powerful, and very convenient, but the examples you
chose are really
poor choices for a variety of reasons.
joe

On Fri, 22 Feb 2008 09:09:32 -0800, "Roger Rabbit" <roger@xxxxxxxxxx>
wrote:

OK is this call a better choice?


AfxBeginThread(WorkerThreadProc,NULL,THREAD_PRIORITY_NORMAL,0,0,NULL);
MessageBox("Thread Started"); // or just go back to something else

where I can change the thread priority to one of the various levels
windows
supports.

To start with I just wanted to thread the paint routine to lean how to do
it
generally. The whole industry is threading everything, I need to be able
too.

Then after the paint routine, why not thread the about box too. Trivial I
agree, but it's the algorithms I am need to learn.

"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
news:ksjtr35kd8qm0gr6maoa84tmmnv79uf0fv@xxxxxxxxxx
IN response to your private email:

What are you painting that takes so long that a thread is required?
Note
that there are
valid cases where this can be so, but the example you sent me is trivial
to the point of
irrelevance.

If you had a very, very complex image to develop, processing it in a
thread can work, but
you need to demonstrate that there is a performance bottleneck related
to
drawing.

Also, since the WM_PAINT method comes into the main GUI thread, you have
to somehow route
it to the secondary thread. This means you cannot declare a PAINTSTRUCT
and use
::BeginPaint, because that would have to be done in the thread that owns
the window. For
that matter, it is not clear why you are doing this when CPaintDC would
do
it for you.

There were three major problems with your example; you said

void WM_PAINT_PROC(HWND hWnd)

If this were intended to be a thread function:
1. The return type is erroneous
2. The calling convention is erroneous
3. The parameter is erroneous

The prototype for a thread function is EXPLICITLY stated in the
documentation as

DWORD WINAPI ThreadProc(LPVOID)

and to change any one of these would result in a failure to compile.

But you should not be using CreateThread, and in using AfxBeginThread,
the
function
prototype is EXPLICITLY stated in the documentation as

UINT function(LPVOID)

and therefore the return type and parameter would be incorrect in your
example, and result
in a failure to compile.

Note that you have done nothing to demonstrate that you are building a
thread that
processes queued entries for drawing; the cost of creating a thread is
not
insignificant,
so you cannot be creating the thread each time you need to paint. The
overhead of thread
creation will probably dominate your drawing time.

If you had a long, complex painting task, you might consider something
along the lines of

void CMyThread::OnDrawRequest(WPARAM wParam, LPARAM)
{
CPaintDC * dc = (CPaintDC *)wParam;
while(something to do)
{
if(aborting painting)
break;
get next item in display list
draw it
}
delete dc;
}


void CMainThread::OnPaint()
{
CPaintDC * dc = new CPaintDC;
drawingthread->PostThreadMessage(UWM_DRAW_REQUEST, (WPARAM)dc);
}

But this is based on the premise that redrawing takes a very, very long
time.
joe

On Thu, 21 Feb 2008 21:40:41 -0800, "Roger Rabbit" <roger@xxxxxxxxxx>
wrote:

The compiler chokes on the at the mythread declaration, I tried cleaning
it
up and reduced the error count 80% and now I am stuck. using VC 08
express.
I gave up on the managed attempt, back to regular c++ which at least
brings
a large pool of skilled people together.

My goal was an easy to use class for threading. The first place I was
going
to use it was in the WM_PAINT_PROC methods I created to draw the screen.
Figured it would be a good place to use a thread. I wish. I used the
Win32
calls and that's the place I am staying for now.

"Tom Walker" <nobody@xxxxxxxxxxx> wrote in message
news:uw7TmBRdIHA.4728@xxxxxxxxxxxxxxxxxxxxxxx
"Roger Rabbit" <roger@xxxxxxxxxx> wrote in message
news:7E2C595C-E864-44BE-8330-05525CC33414@xxxxxxxxxxxxxxxx
Found this from MSDN->codeguru, can't seem to figure out the
problem....

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

Relevant Pages

  • Re: window of vulnerability
    ... that would trigger within a window of vulnerability ... have to be explicit by using some sort of synchronization. ... my question is more oriented toward a security issue. ...
    (comp.lang.java.programmer)
  • Re: window of vulnerability
    ... I heard several times people talking about a security issue known as ... that would trigger within a window of vulnerability ... have to be explicit by using some sort of synchronization. ...
    (comp.lang.java.programmer)
  • Re: window of vulnerability
    ... that would trigger within a window of vulnerability ... have to be explicit by using some sort of synchronization. ... I recently picked up a copy of "Java Concurrency in Practice" <http:// ...
    (comp.lang.java.programmer)
  • Re: XP time set after 7 hours
    ... in a command window... ... > synchronization is normally handled by login script. ... > clients try to synchronize their time with the DC every 7 hours. ... > already disabled internet time synchronization in the clock ...
    (microsoft.public.windowsxp.network_web)