> Crux of the discussion ....Thread is needed where one thinks that a
> aysnc-operation is needed .
Basically you have it. I'd expand it to say when want concurrent tasks.
> In stone-age one used 'interrupts' for this. Right ?.
Maybe interrupts were invented in the computer stone age but they're still
essential. I'll say every (or nearly every) CPU and micro(controller/processor)
uses interrupts. An 'interrupt' is really an indication from the hardware that
an event has happened- I/O pin switched, timer expired, UART Rx/Tx, and so on.
> These days one
> uses a 'watcher-thread' .......
Probably not. Typically you can configure the hardware not to do anything when
your interrupt occurs except flip a register value indicating the event. Your
program can periodically check the value of a register to look for change. This
is referred to as polling but there's usually a trade-off with this
implementation. If you poll too frequently you waste time checking when
nothing's happened. If you poll too slowly you introduce latency from when the
event occurred.
The other method is to register a function pointer or pointers that get called
by the hardware when your interrupt occurs. In this way there's really no
latency and you don't need to worry about the polling concerns I mentioned if
they are actually a concern. In this case your main thread halts execution
where it was at and your interrupt handler is called. The handler returns and
your main thread picks up where it left off.
On your Intel processor I beleive your Windows installation sends some assembly
instructions to register interrupt handlers. I'm pretty certain it's the same
for all the other OS's and processors.
I got a little off subject but hopefully it was helpful.
----- Original Message -----
From: Knowledge Seeker
To: c-prog@yahoogroups.com
Sent: Friday, April 02, 2010 1:02 PM
Subject: Re: [c-prog] MultiThreading !?!
Crux of the discussion ....Thread is needed where one thinks that a
aysnc-operation is needed .
In stone-age one used 'interrupts' for this. Right ?. These days one
uses a 'watcher-thread' .......
Cheers.
Knowledge Seeker
On 4/2/2010 10:21 PM, Gerald Dunn wrote:
> A socket was just a 'real-world' example.
>
> ----- Original Message -----
> From: John Gaughan
> To: c-prog@yahoogroups.com
> Sent: Friday, April 02, 2010 12:20 PM
> Subject: Re: [c-prog] MultiThreading !?!
>
>
>
> On 4/2/2010 9:45 AM, Gerald Dunn wrote:
> > Consider an application that waits for an incoming socket connection.
Typically the function call to accept the connection blocks. Just in case
'blocks' isn't clear, it basically means the function will not return until
some condition is met. In this case the function would not return until an
incoming connection is established or until some other thread closed the server
socket, both of which could be indefinite. If your application just had the one
thread to accept the connection then you could never do anything else. Now
introduce another thread. This new thread could close the server socket after a
timeout or as the result of a button press (physical or graphical), etc.
> >
>
> It doesn't even have to be a socket communication. Any asynchronous
> communication with a separate process may be able to benefit from this
> design.
>
> I have written hardware drivers that used producer-consumer with
> multiple threads on a single system, no sockets involved. But I do agree
> that a good example would be a web server, which does use sockets and
> multiple computers (clients).
>
> --
> John Gaughan
> http://www.johngaughan.net/
>
>
>
>
>
> [Non-text portions of this message have been removed]
>
>
>
[Non-text portions of this message have been removed]
