What if the Producer fills the buffer with information from the internet? It could need to be activated at random times.
--- On Fri, 4/2/10, Knowledge Seeker <[email protected]> wrote: > From: Knowledge Seeker <[email protected]> > Subject: Re: [c-prog] MultiThreading !?! > To: [email protected] > Date: Friday, April 2, 2010, 8:32 PM > This is a good thread to discuss > further. > Now if the tasks rely on each other, I guess they rely on > each other in > some particular sequence/order. Right ? > > [Please recollect my earlier mails for the below example] > I quote, producer-consumer over here. > Consider consumer() as separate thread and producer() as > separate > thread, and 'info-buffer' is shared in between. producer() > fills buffer, > consumer empties is. > You are suggesting to use mutex(or any other > synchronization mechanism) > so that one of the above thread completes the operation > on info-buffer. > Here the particular sequence is > a. producer acquires mutex on buffer. > b. producer fills buffer. > c. producer release mutex on buffer > d. consumer acquires mutex on buffer. > e. consumer fills buffer. > f. consumer release mutex on buffer. > Hence producer -------> consumer order > > I can guarantee the same sequence in single thread. > main() > { > int buffer[10] > producer(buffer); //fills > buffer > consumer(buffer); //empties it > } > use b. and e. steps of the above only. > Still producer -------> consumer order > > Why multi-threading? single threading is simple. > > > On 4/3/2010 1:18 AM, Tyler Littlefield wrote: > > 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: [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] > >>> > >>> > >>> > >>> > >> > >> > > > > > > ------------------------------------ > > > > To unsubscribe, send a blank message > > to<mailto:[email protected]>.Yahoo! > Groups Links > > > > > > > > > > > > ------------------------------------ > > To unsubscribe, send a blank message to > <mailto:[email protected]>.Yahoo! > Groups Links > > > [email protected] > > >
