Author: Vincent Diepeveen
Date: 18:08:40 12/05/00
Go up one level in this thread
<< ps i hope i don' tpost this more as once this message
because here it looks as if i didn't post it correctly as my
ISP disconnected me >>
On December 05, 2000 at 11:48:59, Stefan Meyer-Kahlen wrote:
>On December 05, 2000 at 10:36:09, Vincent Diepeveen wrote:
>
>>On December 05, 2000 at 10:15:31, Robert Hyatt wrote:
>>
>>>On December 05, 2000 at 09:58:39, Vincent Diepeveen wrote:
>>
>>>>Windows is a very sequential system with regard to graphics.
>>>>If some key is hit or a mouse clicks whatever and it goes
>>>>to LRESULT CALLBACK WndProc() or a similar LRESULT CALLBACK
>>>>function then all other threads from the winmain process
>>>>get blocked. Note that this is logical also if you look at it afterwards
>>>>as windows by doing that prevents that you get parallel problems.
>>>>
>>>>Suppose your timer and wndproc do things at the same time! All windows
>>>>applications might start to crash!
>>
>>>One obvious solution, if this problem _really_ exists (and I am not sure
>>>because of the other parallel windows programs) is to have one process for
>>>the GUI, one for the engine, then the engine can thread with no issues.
>>
>>This is exactly what i do.
>>
>>winmain starts a enginecommunication thread,
>>then the engine gets started as a seperated process.
>>If i am multiprocessing then the engine starts more proceses
>>of its own.
>>
>>So just for the engine i have at least 2 processes (GUI, engine)
>>and another extra GUI thread.
>>
>>Now the first problem of this blocking is if you want to close
>>the engine.
>>
>>I discovered the fact that it blocks all threads again when
>>i did next: after user selected 'quit'
>>
>>then in the wndproc somewhere in a subroutine of it i did
>>something like:
>>
>> volatile enginestopped=0;
>> PostMessage(enginethread,STOP_ENGINE);
>> while(!enginestopped);
>
>
>Come on Vince, you cannot post messages to threads but only to windows in
>Windows. Those messages are all handled by your GUI thread that is doing the
>GetMessage()...DispatchMessage() loop. If you consider this the above code can't
>work and produces a deadlock. Btw., did you really do a busy wait here?
No i indeed don't post messages to my enginethread. The enginethread
is only there to listen to the engine, posting to the engine goes
direct from the GUI, not using post or whatever but using shared memory,
so i don't use all those functions at all.
Yet the
while( !waitforenginetoquit );
variable thing i tried :)
It was about the idea that many threads need to wait on each other
because of all kind of windows things. Obviously you can say that i
still am busy learning to program graphical for windows, but that
directly shows my point too... ...it shouldn't be needed!
If in windows multithreading would be cool then next code should work IMHO:
SendToEngine(quit);
// now enginethread waits till it receives from engine that it's
// quitting and then the enginethread sets the variable
while( !waitforenginetoquit ) {
skip;
}
The above code didn't work.
What i do now is i NEVER exit simply if user gives a quit.
I just let the enginethread close the engine. AFTER that proces
is exited only THEN i ship from the enginethread to WndProc a
PostMessage to quit.
Then diep is gone from your screen :)
If there are easier solutions please inform me!
I'm happy to learn tricks to overcome the suffering!
>Check the functions SetEvent(), ResetEvent() and WaitForSingleObject(). There
>are many more functions in Windows dealing with threads and synchronization.
yeah. one i never got to work properly
was for example: SendThreadMessage()
Many of those functions are IMHO cool bugfixes to overcome a bug
in windows somewhere. Like i had the impression (can be wrong)
that if a function doesn't do
what i want that probably some kind of exception is happening and
that they probably invented a cool bugfix for it and directly called
that a different function!
Synchronization? i don't waste system time to
windows functions to do that. i do everything asynchroneous
and getting back acknowledgement can be processed later.
>If you want to make your engine stop try
> bEngineTimeout = TRUE;
> WaitForSingleObject(hEventEngineStopped);
Thanks for the tip!
I get the impression that this is one of the function that
bugfixes for windows the fact that they don't multithread too well
when you're in wndproc() somewhere on the functionstack
or a derived function of it.
How's my feeling?
>and do a
> SetEvent(hEventEngineStopped);
>when the engine is ready or try something similar.
>The disadvantage of the above code is that there is no user input or any
>redrawing possible while waiting, but that should be fine as it usually takes no
>time for the engine to finish. If the engine has crashed you should use a
>maximum timeout in the wait, but you can also make the engine post a message
>when it is ready, there are many ways how to handle this and it can be done for
>sure.
I always assume diep doesn't crash, sorry.
But despite that i indeed have a timeout yes.
>I think once you get used to it the windows API is fine.
Yes indeed, as i said you need to learn a lot to avoid
bugs, and indeed after a while you don't even notice it anymore,
you just deal with it: "as it got to run whatever".
But perhaps like Bob i'm probably a purist in this sense that
i would prefer to NOT need to know to do something which
normally isn't possible under a certain condition as they
have a bug in the multithreading.
Thanks,
Vincent
>Stefan
>>To my horror the STOP_ENGINE message never arrived at the
>>enginethread.
>>
>>Took me 1 week to realize that it wasn't a bug somewhere
>>but that it was the wonderful 'garantuee' from Microsoft that
>>prevents parallel problems.
>>
>>Welcome to windows!
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.