Board index » cppbuilder » Threads and OnEvents

Threads and OnEvents

Before I start, thanks to who ever it was that pointed me to the TComPort
component, it seems to work okay, although I haven't used it in anger yet.

Thread Questions:

1)  What difference does using delete <object> or using the Terminate method
do to a Thread?  Should you only use Terminate?

2)  If a Thread is waiting on an Event, will terminate actually terminate
the thread, or should the SetEvent be actioned to wake up the thread?

3)  Is it possible to send a user defined event to the main form thread from
a thread?  Or is the only way to signal an event to the main thread to use a
callback method?  If both can be used what are the hazards of either?

Finally, not a Thread question, what are the pros/cons between using IPC or
opening Client/Server socket connections between two or more applications?

I tried it out today, having a TraceWindow application with a server socket,
and client socket applications sending debug information, it seemed to work
quiet well and was easy to do, have I missed something?

 

Re:Threads and OnEvents


I think I can give some form of answer to the first two of you questions.

Deleting the thread object is not a good idea, as it pulls the rug from
underneath the thread and may well leave data structures in a damaged state.
Applying the Terminate method to the thread from outside the thread is a
request to terminate which means that the thread can decide itself when to
exit and what work needs to be done before doing so.  It means that the
thread has to regularly inspect the "Terminated" property and act
accordingly.  The requestor of the terminate can use the "WaitFor" method to
see when the thread has terminated.  In short, you should always use the
terminate method.

As far as the second question is concerned,  as long as the thread has not
been actually suspended, it should be able to still poll the "Terminated"
property.  I am not sure as to what state your thread will be in waiting for
the event - suspended ready to be resumed by the event or still executing
and polling for the event.

I hope that this is helpful

John

Quote
"paul" <plma...@clara.co.uk> wrote in message news:3b4f49c0_2@dnews...
> Before I start, thanks to who ever it was that pointed me to the TComPort
> component, it seems to work okay, although I haven't used it in anger yet.

> Thread Questions:

> 1)  What difference does using delete <object> or using the Terminate
method
> do to a Thread ?  Should you only use Terminate?

> 2)  If a Thread is waiting on an Event, will terminate actually terminate
> the thread, or should the SetEvent be actioned to wake up the thread?

> 3)  Is it possible to send a user defined event to the main form thread
from
> a thread?  Or is the only way to signal an event to the main thread to use
a
> callback method?  If both can be used what are the hazards of either?

> Finally, not a Thread question, what are the pros/cons between using IPC
or
> opening Client/Server socket connections between two or more applications?

> I tried it out today, having a TraceWindow application with a server
socket,
> and client socket applications sending debug information, it seemed to
work
> quiet well and was easy to do, have I missed something?

Re:Threads and OnEvents


Quote
paul wrote:

> Before I start, thanks to who ever it was that pointed me to the
> TComPort
> component, it seems to work okay, although I haven't used it in anger
> yet.

> Thread Questions:

> 1)  What difference does using delete <object> or using the Terminate
> method
> do to a Thread?  Should you only use Terminate?

Yes - always terminate the thread first before deleting the thread
object (although you could try putting the Terminate call in the
destructor...maybe that would work!)
Quote

> 2)  If a Thread is waiting on an Event, will terminate actually
> terminate
> the thread, or should the SetEvent be actioned to wake up the thread?

If the thread is waiting for an event it is in a deep sleep so calling
terminate will not have any effect until the event occurs. So it is best
to place a SetEvent call inside the thread's Terminate method prior to
calling the base Terminate method.

Quote
> 3)  Is it possible to send a user defined event to the main form
> thread from
> a thread?  Or is the only way to signal an event to the main thread to
> use a
> callback method?  If both can be used what are the hazards of either?

Yes, you can send a user-defined event to the main form from within a
thread. I uses this technique to post a WM_USR_HEARTbeat event to the
main thread as a watchdog to ensure that all threads are running. If I
miss a heartbeat, the main thread can terminate the offending thread and
try to re-create it. (PostMessage(...)
Quote

> Finally, not a Thread question, what are the pros/cons between using
> IPC or
> opening Client/Server socket connections between two or more
> applications?

I currently use named pipes IPC successfully between two or more apps
(on the same or separate m/cs), but I think the technique is now
superseded by using sockets. Named pipes take quite a lot of coding, and
really require threading to work efficiently (due to blocking), whereas
sockets are relatively trivial to get working...

--
......................................................................
Men never do evil so completely and cheerfully as when they do it from
religious conviction.

Blaise Pascal, philosopher and mathematician (1623-1662)

Re:Threads and OnEvents


Thankyou.  The answers were what I suspected, but just needed someone to
confirm it.

I'll try PostMessage() tomorrow.

I must admit, the thought of setting up IPC was a bit terrifying, which is
why I tried Sockets to start off with.

Its very different writing code for Win32 compared with embedded OSs.

Quote
"Colin Attwell" <co...@new.co.za> wrote in message

news:3B4FF402.3EB7152D@new.co.za...
Quote
> paul wrote:

> > Before I start, thanks to who ever it was that pointed me to the
> > TComPort
> > component, it seems to work okay, although I haven't used it in anger
> > yet.

> > Thread Questions:

> > 1)  What difference does using delete <object> or using the Terminate
> > method
> > do to a Thread?  Should you only use Terminate?

> Yes - always terminate the thread first before deleting the thread
> object (although you could try putting the Terminate call in the
> destructor...maybe that would work!)

> > 2)  If a Thread is waiting on an Event, will terminate actually
> > terminate
> > the thread, or should the SetEvent be actioned to wake up the thread?

> If the thread is waiting for an event it is in a deep sleep so calling
> terminate will not have any effect until the event occurs. So it is best
> to place a SetEvent call inside the thread's Terminate method prior to
> calling the base Terminate method.

> > 3)  Is it possible to send a user defined event to the main form
> > thread from
> > a thread?  Or is the only way to signal an event to the main thread to
> > use a
> > callback method?  If both can be used what are the hazards of either?

> Yes, you can send a user-defined event to the main form from within a
> thread. I uses this technique to post a WM_USR_HEARTbeat event to the
> main thread as a watchdog to ensure that all threads are running. If I
> miss a heartbeat, the main thread can terminate the offending thread and
> try to re-create it. (PostMessage(...)

> > Finally, not a Thread question, what are the pros/cons between using
> > IPC or
> > opening Client/Server socket connections between two or more
> > applications?

> I currently use named pipes IPC successfully between two or more apps
> (on the same or separate m/cs), but I think the technique is now
> superseded by using sockets. Named pipes take quite a lot of coding, and
> really require threading to work efficiently (due to blocking), whereas
> sockets are relatively trivial to get working...

> --
> ......................................................................
> Men never do evil so completely and cheerfully as when they do it from
> religious conviction.

> Blaise Pascal, philosopher and mathematician (1623-1662)

Re:Threads and OnEvents


Thanks

Quote
"John Blackburn" <john.blackb...@lintonhealy.co.uk> wrote in message

news:3b4f5cbb_1@dnews...
Quote
> I think I can give some form of answer to the first two of you questions.

> Deleting the thread object is not a good idea, as it pulls the rug from
> underneath the thread and may well leave data structures in a damaged
state.
> Applying the Terminate method to the thread from outside the thread is a
> request to terminate which means that the thread can decide itself when to
> exit and what work needs to be done before doing so.  It means that the
> thread has to regularly inspect the "Terminated" property and act
> accordingly.  The requestor of the terminate can use the "WaitFor" method
to
> see when the thread has terminated.  In short, you should always use the
> terminate method.

> As far as the second question is concerned,  as long as the thread has not
> been actually suspended, it should be able to still poll the "Terminated"
> property.  I am not sure as to what state your thread will be in waiting
for
> the event - suspended ready to be resumed by the event or still executing
> and polling for the event.

> I hope that this is helpful

> John

> "paul" <plma...@clara.co.uk> wrote in message news:3b4f49c0_2@dnews...
> > Before I start, thanks to who ever it was that pointed me to the
TComPort
> > component, it seems to work okay, although I haven't used it in anger
yet.

> > Thread Questions:

> > 1)  What difference does using delete <object> or using the Terminate
> method
> > do to a Thread ?  Should you only use Terminate?

> > 2)  If a Thread is waiting on an Event, will terminate actually
terminate
> > the thread, or should the SetEvent be actioned to wake up the thread?

> > 3)  Is it possible to send a user defined event to the main form thread
> from
> > a thread?  Or is the only way to signal an event to the main thread to
use
> a
> > callback method?  If both can be used what are the hazards of either?

> > Finally, not a Thread question, what are the pros/cons between using IPC
> or
> > opening Client/Server socket connections between two or more
applications?

> > I tried it out today, having a TraceWindow application with a server
> socket,
> > and client socket applications sending debug information, it seemed to
> work
> > quiet well and was easy to do, have I missed something?

Re:Threads and OnEvents


Quote
paul wrote:

> I must admit, the thought of setting up IPC was a bit terrifying,
> which is
> why I tried Sockets to start off with.

It's not too terrible actually, in the Win32 help file there is a very
complete example of how to do it - including multi-threading it, which
you can just cut & paste and make a very good start. In fact the
complete example is 100% working IIRC. But stick to sockets - I suspect
they're more likely to persist into future incarnations.
Quote

> Its very different writing code for Win32 compared with embedded OSs.

The biggest pain for me is that (particularly in WinNT & W2K) is that
access to all hardware resources is completely wrapped in M$ code. How
arrogant to assume that they know ahead of time what all my access needs
will be. To circumvent this requires in several orders of magnitute
increase in pain and nausea to write your own driver which almost
certainly requires obtaining VC++ as well as the obligatory DDK.

Re:Threads and OnEvents


Quote
Colin Attwell <co...@new.co.za> writes:

> > Its very different writing code for Win32 compared with embedded OSs.

> The biggest pain for me is that (particularly in WinNT & W2K) is that
> access to all hardware resources is completely wrapped in M$ code. How
> arrogant to assume that they know ahead of time what all my access needs
> will be.

Actually, that's the JOB of the operating system.  If you are allowed
direct hardware access, then the OS cannot maintain a consistent
environment.  It cannot be secure, it cannot prevent your application
form affecting other applications from running.  And so on.  

Quote
> To circumvent this requires in several orders of magnitute
> increase in pain and nausea to write your own driver which almost
> certainly requires obtaining VC++ as well as the obligatory DDK.

So why not just use the routines provided by the OS?

--
Chris (TeamB);

Re:Threads and OnEvents


Quote
Chris Uzdavinis (TeamB) wrote:
> Actually, that's the JOB of the operating system.  If you are allowed
> direct hardware access, then the OS cannot maintain a consistent
> environment.  It cannot be secure, it cannot prevent your application
> form affecting other applications from running.  And so on.

yahdda, yahdda, yahdda...I know and understand all the reasons why,
but...

Quote

> So why not just use the routines provided by the OS?

the OS provided routines whilst being sufficient for most needs are not
adequate for all possible requirements. I'll give you a case in point. I
have written an application that communicates with a whole bunch of
devices via RS484 in a half-duplex multi-drop way. My protocol requires
very fine control over the "transmit control" to turn off the tranmitter
at the end of a message (it's a bandwidth thing!). The best W2K has
achieved in this department varies between 5 and 25 ms (at 38k baud).
I'd like a guarenteed time of no more than 1ms or better - so out with
the driver writing handbook.

Also, although I havn't needed to yet, I belive that using the parallel
port for anything other than talking to a printer is also deficient, but
I'm talking heresay here...

--
......................................................................
Men never do evil so completely and cheerfully as when they do it from
religious conviction.

Blaise Pascal, philosopher and mathematician (1623-1662)

Re:Threads and OnEvents


Quote
> the OS provided routines whilst being sufficient for most needs are not
> adequate for all possible requirements. I'll give you a case in point. I
> have written an application that communicates with a whole bunch of
> devices via RS484 in a half-duplex multi-drop way. My protocol requires
> very fine control over the "transmit control" to turn off the tranmitter
> at the end of a message (it's a bandwidth thing!). The best W2K has
> achieved in this department varies between 5 and 25 ms (at 38k baud).
> I'd like a guarenteed time of no more than 1ms or better - so out with
> the driver writing handbook.

So using Windows is probably the wrong decision

Torsten

Re:Threads and OnEvents


Quote
Torsten Franz (TeamBeer) wrote:
> So using Windows is probably the wrong decision

That's a given ;->

However, the app is firmly in the Windows environment and despite my
wishes to port it to Linex, marketing is selectively deaf in that
particular ear...

(Love the TeamBeer!)
--
......................................................................
Men never do evil so completely and cheerfully as when they do it from
religious conviction.

Blaise Pascal, philosopher and mathematician (1623-1662)

Re:Threads and OnEvents


One of the projects my team has been invovled with is a multidrop system to
up to 100 devices, using NT, and that too also required a specialised NT
driver.

You can't beat a real OS.  Its just a shame that the money and jobs are all
in the Win32 market.

Quote
"Colin Attwell" <co...@new.co.za> wrote in message

news:3B532899.DFAF7B0A@new.co.za...
Quote
> Torsten Franz (TeamBeer) wrote:
> > So using Windows is probably the wrong decision

> That's a given ;->

> However, the app is firmly in the Windows environment and despite my
> wishes to port it to Linex, marketing is selectively deaf in that
> particular ear...

> (Love the TeamBeer!)
> --
> ......................................................................
> Men never do evil so completely and cheerfully as when they do it from
> religious conviction.

> Blaise Pascal, philosopher and mathematician (1623-1662)

Re:Threads and OnEvents


Quote
paul wrote:

> One of the projects my team has been invovled with is a multidrop
> system to
> up to 100 devices, using NT, and that too also required a specialised
> NT
> driver.

> You can't beat a real OS.  Its just a shame that the money and jobs
> are all
> in the Win32 market.

Would you be interested in parting with your driver, like for money or
something??? ;->

Our system potentially can grow to 256 devices, before which point
bandwidth becomes like hen's teeth, very scarce and precious!

Other Threads