|
| From: | Richard Frith-Macdonald |
| Subject: | Re: Threads, DO and Runloop unexpected behaviour |
| Date: | Tue, 1 Nov 2005 16:25:21 +0000 |
On 1 Nov 2005, at 14:54, Wim Oudshoorn wrote:
I am using DO to communicate between threads. In the following simple example we have 3 threads. - Worker thread, handling requests from thread A and B - thread A performing -doInternal on the Worker thread - thread B perfomring -doExternal on the Worker thread Now the doExternal thread will wait until something happens and in order to avoid blocking all other work, it will explicitly run the runloop. So during execution of -doExternal it should be possible that thread A gets its requests for -doInternal processes. However, it sometimes does NOT!
Well, the main (Worker) thread handles the requests, and two other threads make the requests. Since only one thread is handling requests, you can't have both running at the same time ... so the 'perfect' situation would be that you see calls to -doInternal and -doExternal alternating. However, chance and the system scheduler could do things differently ...
Consider a single CPU system ... Say -doExternal is executing.execution finishes, and the main thread sends out a network response to thread B telling it the request has completed. The system scheduler gives thread B control, and it immediately makes a new request to execute -doExternal again ... which causes a network write back to the worker thread. The system scheduler gives the worker thread control again ... it can see two readable network connections (one with a request from thread B and one with a request from thread A) it selects one to handle first ... the one from thread A ... so it does a second -doExternal without an intervening -doInternal.
This is moderately rare, since chances are the scheduler will give the main thread control back before thread B can produce its new request. It would be more rare on a multi-cpu system, since the worker thread and thread A might be on different CPUs, and the worker thread is likely to be handling thread Bs request before thread A even knows that its request has completed.
| [Prev in Thread] | Current Thread | [Next in Thread] |