@Gambit,
Thanks for your time and remarks.
Quote
>Just before MyThread suspends itself, it sends a message to MyMainForm.
How, exactly?
I handover a 'MyMainForm_Pointer' to MyThread by a thread constructor
argument.
Then inside the thread I use;
PostMessage(MyMainForm_Pointer->Handle,MY_MSG_TYPE,0);
This message just works fine.
Quote
Why not just have the thread signal the event directly?
Because the signal-event (CreateEvent(MyEvent)) is declared in MyMainForm.
To signal it from within MyThread I need a handle to MyEvent inside
MyThread. (I think...)
So another MyThread constructor argument would do but I thought lets try it
with a message.
As WaitForSingleObject blocks execution of the Synchronize()-argument
function it does not matter directly signalling MyEvent or doing it by a
message from inside the argument-function because the argument-function will
never be executed.
What eventually could be the advantage of directly resetting MyEvent over
using messages to do so?
Quote
If the main thread is blocked because of your loop, then there are no
messages being processed, and thus the thread's message is not being
received in order to signal the event.
WaitForSingleObject() is a blocking function. It does not process the
message queue at all.
Thats the crux I did not know!
I solved it by:
//test each 1ms if event is signalled
while((dwRes=WaitForSingleObject(pMyEvent,1))==WAIT_TIMEOUT){
Application->ProcessMessages()
}
Although it's not a nice solution then an endless timeout is not detected
because now WAIT_TIMEOUT is used in a
tricky way.
There must be some more reliable method.
============================================================
I'm working on an application that communicates with a small Robot (Asuro)
by infrared signals through the comport. The comport object uses 4 events
with WaitForMultipleObjects to control WriteFile() and ReadFile()
operations. This all works fine.
I need the comport object to exchange data through 'shared resources' with
the rest of my application.
My first idea was to not have to worry about data overflows
sending/receiving data to/from the comport. So I figgered out that using
ringbuffers with underrun/overflow detection would do best.
My application (user-object) sends tx-data, byte by byte, to the
tx-ringbuffer which in turn is read by the comport-object to be transmitted
using WriteFile(). The same accounts for receiving infrared data, namely the
comport-object reads received data by ReadFile() and puts each received
character into the rx-ringbuffer. A low level thread then reads the
rx-ringbuffer.
To not get atomic errors I use 4 ringbuffer threads with mutexes:
1. a tx-ringbuffer-write-thread
2. a tx-ringbuffer-read-thread
3. a rx-ringbuffer-write-thread
4. a rx-ringbuffer-read-thread
both tx-threads use a tx-mutex
both rx-threads use a rx-mutex
(I first used two same ringbuffer-objects (tx and rx) from the same
ringbuffer class but debugging got very confusing as the de{*word*81} accesses
the ringbuffer sourcecode without knowing if its the tx- or rx- ringbuffer
now debugging....so during development I use two equally ringbuffer (tx and
rx) classes)
The function of the threads is to exchange characters between user-object or
comport-object and both ringbuffers. The only thing I would like to worry
about is putting characters into the tx-ringbuffer and read characters from
the rx-ringbuffer.
Using mutexes, for example, if no tx-ringbuffer-write nor tx-ringbuffer-read
operation is in process then both corresponding tx-threads
WaitForSingleObject(Mutex,Delay) functions will continuously being
signalled. Therefore I let all threads suspend itself to not spill
processortime. Reading/writing ringbuffer operations always starts with a
thread-resume.
If I want a character to be transmitted by the comport, the user-object:
- stores the transmit character into a tx-ringbuffer-write-thread variable
- resumes the tx-ringbuffer-write-thread (which through the comport-object
resumes the tx-ringbuffer-read thread)
Now I would like the program to wait, using no processortime, until the
tx-character really has been written into the tx-ringbuffer by the comport
object. Therefore I thought to use a WaitForSingleObject function to wait
for a signal from the tx-ringbuffer-write-thread that writing has been
finished. The tx-ringbuffer-write-thread signals this event just prior to
suspending itself.
So in short:
Tx:
1. the user-object writes a tx-character into tx-ringbuffer
2. the comport-object reads a tx-character from ringbuffer, then transmits
it by WriteFile()
Rx:
3. the comport-object receives a rx-character by ReadFile(), then writes it
into rx-ringbuffer
4. the user-object reads a rx-character from rx-ringbuffer
I saw programs that POLL the comport-object. Maybe my approach according the
comport is not such a good idea...
But again, ideas are welcome.
Regards,
Henk