Re: Explain this about threads

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


"Rick Lones" <WrlonesX@xxxxxxxxxxxxx> wrote in message
news:3xjJi.1106$BR5.153@xxxxxxxxxxxxxxx
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.


Ok, these are locks... but who implements them? I can't see how a program
can block itself to task scheduling... except maybe it blocks but then
something else has to unblock.

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.

Ok, so your saying essentially when a synchronous call is made that requires
a resource that you block yourself? Somehow you say "I'll wait until the
resource is free"... but then something else must unblock. But it would
seem then to do any type of blocking you have to know explicitly the
resource to block on so whatever else can unblock. Seems more complicated
than just having the other thing block and unblock.


What I mean is that it makes more sense to me for whatever that is
controlling the resource to control blocking and unblocking.

Example.

Program:
Hey, Save this file

Resource Handler:
(Internally to scheduler: Block Program,
Save the file,
Return status msg and unblock program)
Ok, I saved it.
------

instead of

Program:
Hey, Save this file
(tell scheduler to block me)

Resource Handler:
(Internally to scheduler:
Save the file,
Return status msg and unblock program)
Ok, I saved it.


I guess though it doens't quite matter where it does it and maybe its
actually better for the program to block itself.. just seems like theres no
context there and it could block itself for any reason even if the resource
handler doesn't need to block.(which I guess would be asynchronous commm)

so for something like text output,


Program:
Hey, print x to screen

Resource Handler:
Queue x to be printed
------


instead of

Program:
Hey, print x to screen
(tell scheduler to block me)

Resource Handler:
(Internally to scheduler:
Queue x to be printed
Return status msg and unblock program)
----


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.


Well, it would be nice if I had time but I got so much other stuff to do. I
know the basics but I need to understand how it all fits together. Maybe
one day I'll actually read a book on it. (I used to program protected mode
back in the day when it was a big deal... but forgot a lot of the stuff and
never really got to much past writing a task switcher.)

I think eventually I will take a look at some embedded operating systems
because I'll probably need one in the future but at this point I just want
to write a program to compute with some devices I have that use some
protocols(ICSP, I2C and SPI). I want it ot be general enough so I program
these protocols in a nice way(instead of hard coding them). That way if the
future if I want to add another one such as modbus or rs-232(emulated on the
parallel port by polling... or just end up using the serial port) I can
without to much trouble.


.

Relevant Pages

  • Re: Explain this about threads
    ... except maybe it blocks but then something else has to unblock. ... a resource that you block yourself? ... But the basic blocking behavior itself, being based on the individual character reads and not the newline per se, _is_ in fact managed by the OS, and not your thread). ... (Internally to scheduler: Block Program, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Explain this about threads
    ... synchronize tasks on resources, see "semaphore". ... 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. ... except maybe it blocks but then something else has to unblock. ... 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? ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Leveling problem
    ... > scheduler could ... >> creates the time to do the data management block, ... Your resource says Oops, I did ... >>> because than I am leveling by hand and not by Project. ...
    (microsoft.public.project)
  • Re: Scheduling task service with failover
    ... The Task Scheduler resource would actually have to be active on the node ... >> database (registry hive). ... >> the shared job information is stored on the shared disk. ...
    (microsoft.public.windows.server.clustering)
  • Re: threading - Monitor.Wait/Pulse
    ... and releases the lock on the monitored object. ... a thread calls Pulseon the Monitor, the first thread in the Wait Queue ... will thread 3 then get the resource or will thread 1 get ... When Thread1 calls Wait on the monitor object, ...
    (microsoft.public.dotnet.general)