Re: Multi-threading architecture
- From: "Danny Kellett" <nospam@xxxxxxxxxxxxxxxxx>
- Date: Tue, 25 Oct 2005 13:00:47 +0100
What an outstanding explaination. Have not thought of that before.
Thanks
"David Schwartz" <davids@xxxxxxxxxxxxx> wrote in message
news:dhdn31$t2s$1@xxxxxxxxxxxxxxxxxxxxx
>
> "jambu" <karthikeyan.jambulingam@xxxxxxxxx> wrote in message
> news:1127886324.081331.298240@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
>> Sorry for the late reply . I use a proper Thread pool , I make the
>> thread to wait using pthread_cond_wait function before which i change
>> its status to waiting . And when i check thread pool and find a thread
>> to be in the waiting state , the waiting state is released and the
>> request is passed to it .
>
> No, no, no! Don't pick a thread to hand the request to. Let whichever
> thread happens to run (or be running) take the request off the queue
> itself.
>
> If you have a bunch of truck drivers milling around the office, which
> is better:
>
> 1) Put a job where they can all see it and let whoever sees it first do
> it, or
>
> 2) Put the name of a truck driver on a job and let it wait until that
> particular person sees it.
>
> Imagine if thread A is working at full speed. Thread B is doing
> nothing. So you assign the job to thread B. But if there's no available
> CPU and thread B isn't scheduled, when thread A finishes the job it's
> working on, you pointlessly force a context switch to thread B before you
> let the job be worked on. Thread A could just pull it off the queue --
> it's already running. Maybe by the time thread B is scheduled there will
> be even more work for it to do.
>
> DS
>
>
.
- Follow-Ups:
- Re: Multi-threading architecture
- From: Ken Chevasin
- Re: Multi-threading architecture
- Prev by Date: Re: Lock vs Lock-free programming
- Next by Date: Implementing a blocking queue on top of a non-blocking one
- Previous by thread: Re: Multi-threading architecture
- Next by thread: Re: Multi-threading architecture
- Index(es):
Relevant Pages
|