The tasks may rely on each other, in which case a mutex or something similar
can be used to either keep a variable or a thread can monitor a variable to
make sure that another thread has completed a specific operation. They don't
have to be independant of each other.
Thanks,
Tyler Littlefield
http://tds-solutions.net
Twitter: sorressean
On Apr 2, 2010, at 11:55 AM, Knowledge Seeker wrote:
> 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: 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]
> >
> >
> >
>
>
------------------------------------
To unsubscribe, send a blank message to
<mailto:c-prog-unsubscr...@yahoogroups.com>.Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/c-prog/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/c-prog/join
(Yahoo! ID required)
<*> To change settings via email:
c-prog-dig...@yahoogroups.com
c-prog-fullfeatu...@yahoogroups.com
<*> To unsubscribe from this group, send an email to:
c-prog-unsubscr...@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
