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: 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 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/
