Re: Explain this about threads

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Jon Slaughter wrote:
"Rick Lones" <WrlonesX@xxxxxxxxxxxxx> wrote in message news:q_6Ji.1$aa4.0@xxxxxxxxxxxxxxx
Jon Slaughter wrote:
"Instead of just waiting for its time slice to expire, a thread can block each time it initiates a time-consuming activity in another thread until the activity finishes. This is better than spinning in a polling loop waiting for completion because it allows other threads to run sooner than they would if the system had to rely solely on expiration of a time slice to turn its attention to some other thread."



I don't get the "a thread can block each time...". What does it mean by blocking? Does it mean that if thread B needs something from thread A that thread A stops thread B from running until its finished but not interfer with some other thread C?

More like thread B stops itself from running until A has made some resource available or raised some other kind of event. There is usually no reason to sit and spin in the meantime, so normally the remainder of B's time slice would be yielded to the scheduler in hopes that some other task has a use for the CPU resource. B is now said blocked to be "blocked" on some event and will not be rescheduled until the event occurs. It's less exotic than it may sound - if A is the operating system, e.g., this happens every time your task B does a synchronous wait for any OS resource, for example Console.Readline().



Ok, but I don't understand the "blocked on some event and will not be rescheduled until the event occurs". How does that happen? I can't picture how the machinery is setup to do this.

For an example of the type of low-level "machinery" that can be used to synchronize tasks on resources, see "semaphore". A semaphore can be viewed as a data structure which represents a resource or event. One key aspect of a classic OS semaphore structure is a queue to which tasks awaiting the resource or event can chain their task control blocks.

If we use your example of ReadLine() then essentially what happens is eventually the call works its way down to a hardware driver. But this requires a task switch somewhere to go from user mode to kernel mode. Now wouldn't the scheduler try and "revive" the user mode code that was tasked switched because it wouldn't know that its waiting for the kernel mode code to finish?

But "it" does know - because your task has called ReadLine()! That announces that your task cannot continue until an Environment.NewLine has been registered at the keyboard. You have blocked yourself until an I/O operation completes.

As for the scheduler: you could think of it as managing a bunch of queues whose contents are task control blocks. One of these is the Ready queue, consisting of task which are runnable. A task is removed from the Ready queue when it blocks and is put back onto this queue when the event it is awaiting occurs. While not on the Ready queue, it is never even looked at for scheduling. Caveat: I am describing a simplified and idealized OS here, NOT the down and dirty details of any particular Windows OS. But the model is accurate enough to be useful.

And for a quick handwave at the driver level: Somewhere somehow in some form there is a semaphore or some equivalent which represents the event "a line of text was entered at the keyboard". Your task's control block was placed on that semaphore's queue when you called ReadLine() and there it will sit until some interrupt handler recognizes that the event has occurred and "posts" the event to the semaphore. This "post" operation causes a task (yours) which has been waiting on this semaphore to be removed from the semaphore's queue and placed back on the scheduler's Ready queue. Voila - your awaited event has occurred andy you are now runnable again. (Again, a generic but useful model of the kinds of things that take place.)


Or is there some information in a task switch like a lock or something that tells the scheduler not to revice a process and the kernel mode code would determine that.

Hence I suppose in the task switch state one might have something like "IsBlocked". When the kernel mode is entered, if its asynchronous is might set IsBlocked momentarily but then release it. If its synchronous then it would set IsBlocked until it is completely finished.

Am I way off? ;) Its just hard for me to understand how the internal machinery accomplishes this. Maybe is as simple as a lock though?

You sound like someone who is ready to appreciate a good book on Operating System basics. :) If you want to see the guts of a simple and approachable OS explained at a very useful level of detail you might start with LaBrosse's description of his uC/OS. This is a bare-bones multitasking OS intended for embedded systems.

Regards,
-rick-
.

Relevant Pages

  • Re: about semaphore
    ... But when should we allow a resource to be accessed by more than one thread ... For message queue, we usually allow all thread to read, and when queue is ... I searched in google for semaphore usage, only found many definition, but no ... > CreateSemaphore(NULL, lInitCount, lMaxCount, null); ...
    (microsoft.public.vc.language)
  • Re: preventing multiple app instances under Win XP (fast user switching)?
    ... One of the most commonly used techniques for ... mutual exclusion is the semaphore. ... The value of a semaphore is the number of units of the resource which are ... a semaphore may have an associated queue of processes ...
    (microsoft.public.vb.winapi)
  • Re: preventing multiple app instances under Win XP (fast user switching)?
    ... One of the most commonly used techniques for ... mutual exclusion is the semaphore. ... The value of a semaphore is the number of units of the resource which are ... a semaphore may have an associated queue of processes ...
    (microsoft.public.vb.general.discussion)
  • Re: How to get synchronized efficiently
    ... A semaphore, behaving as a mutex, is one way to protect access to a queue. ... The choice of the best sync model ALWAYS depends on the design of your ... Let's set aside IOCP and consider the semaphore case. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Multithreaded queue with wait event
    ... if two threads release the mutex and are just about to ... See, if that happens, one thread will receive the event and dequeue. ... your queue can indeed return no item when there is no timeout ... I have two implementations, one using the semaphore, the other using ...
    (comp.programming.threads)