On 4/2/2010 11:00 PM, Gerald Dunn wrote:
>> 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.
>
Do the 'concurrent tasks' means ... non-dependable / independent
concurrent tasks ? By independent I mean there is no concept of
producer-consumer, as the producer-consumer are dependent on each other
to fill-empty the buffer they share in between.
>
>> 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.
>
>
'Polling' is logically equivalent to creating a watcher-thread; where we
wait for something to happen. The difference is that polling is used in
micro-processor level and watcher thread is used in application layer.
eg: I poll for if data has come in serial-port or not. (Polling) or I
poll for that directory contents are changed (some new addition of file
/ deletion of file)or not (Keeping a directory watcher-thread).
> 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.
>
>
I got this point too. Interrupt handler is logically equivalent
event-handler design. Where we register a call-back event handler
function, which is called in response to when some event has occurred.
Something like:
funchandler()
{
//do something when event-id comes
}
main()
{
Register(funchandler, eventid);
/// do some processing
// continue more processing
}
But still here a different thread will be used
CPUThread()
{
PostEvent(eventID); //this will post event
}
In the above main() is first thread, while funchandler() gets called in
the thread-context of CPUThread().
Right ?
But then this is also multi-threading ... we are having two threads in
this scenario.
Hence my original thought 'Whenever we think of async operation, we
think of multithreading'.
> 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: [email protected]
> 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: [email protected]
> > 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]
>
>
>
