Thread Scheduler per processor but thread database???

NTDEV
1

Hi

In multicore or multiprocessor systems, thread scheduler can work on every processor at the same time. Right?

Is there a global thread queue that CPUs look up to select a thread or also thread database (or queue) is per processor as well?

If it is per processor my question is, if I build a simple MFC dialog window and run it, why don’t I see the same number of window equal to my CPU’s core number. Because every core can select to run the thread that runs UI.

Other question is,so, If I create a thread, do I always protect it with mutex to not be able to be run concurrently by other cores?

2

Maybe others will answer your questions but I believe you should read this book http://technet.microsoft.com/en-us/sysinternals/bb963901.aspx. It will answer your current and all subsequent questions which will raise immediately.

Previous editions would be also useful, basic concepts didn’t change.

Michal

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-512295-
xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Monday, September 03, 2012 8:41 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Thread Scheduler per processor but thread database???

Hi

In multicore or multiprocessor systems, thread scheduler can work on every
processor at the same time. Right?

Is there a global thread queue that CPUs look up to select a thread or also
thread database (or queue) is per processor as well?

If it is per processor my question is, if I build a simple MFC dialog window and
run it, why don’t I see the same number of window equal to my CPU’s core
number. Because every core can select to run the thread that runs UI.

Other question is,so, If I create a thread, do I always protect it with mutex to
not be able to be run concurrently by other cores?

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately.
Thank You!
AuthenTec, Inc. http://www.authentec.com/

3

On 03-Sep-2012 09:41, xxxxx@gmail.com wrote:

In multicore or multiprocessor systems, thread scheduler can work on every processor at the same time. Right?

This is undocumented. The general rule is, do not assume on undocumented
details, and accept as much as is reasonable.

Is there a global thread queue that CPUs look up to select a thread or also thread database (or queue) is per processor as well?

On certain kind of systems, threads have their “ideal CPU”. So there
should be some way to mark this association. Also, there may be ways to
reduce contention on the scheduler database, such as assigning a
“standby” thread to a CPU. Again, this is undocumented.

If it is per processor my question is, if I build a simple MFC dialog window and run it, why don’t I see the same number of window equal to my CPU’s core number. Because every core can select to run the thread that runs UI.

Maybe, because you don’t explicitly manage the affinity. Then you cannot
expect anything.

Other question is,so, If I create a thread, do I always protect it with mutex to not be able to be run concurrently by other cores?

Hmm, that’s already paranoia.

– pa

4

> Hmm, that’s already paranoia.

No, this is just a lack of basic understanding of how the OS works and what the thread is. What truly amazes me is the fact that the OP has been asking questions here for almost 2 years of more or less regular basis - he does not seem to have proceeded anywhere, don’t you think…

Anton Bassov

5

Buy the book and read it. Please. Read sections that interest you twice.

It’s not that we don’t want to answer your question here, it’s that it’d take a few pages of text – or an in-person lecture – to answer it properly.

Peter
OSR

6

> Hi

In multicore or multiprocessor systems, thread scheduler can work on every
processor at the same time. Right?

Why does it matter?

Is there a global thread queue that CPUs look up to select a thread or
also thread database (or queue) is per processor as well?

Why does it matter?

If it is per processor my question is, if I build a simple MFC dialog
window and run it, why don’t I see the same number of window equal to my
CPU’s core number. Because every core can select to run the thread that
runs UI.

I have no idea what you mean by “the same number of window equal to my
CPU’s core number.” Windows are not associated with CPUs, they are
associated with threads, and consider the following scenario: you have an
EN_CHANGE notification for your edit control. You have no idea from
keystroke to keystroke which core will be executing the code. The
scheduler will schedule the thread, and which core it schedules it to is
undefined, as far as you are concerned.

Any thread can normally run on any core, and unless you have established a
preferred processor or set thread affinity, you don’t control it, you
don’t know it, and most important, YOU DON’T CARE!

There is only one thread for the entire GUI.

Other question is,so, If I create a thread, do I always protect it with
mutex to not be able to be run concurrently by other cores?

It is considered Poor Practice to ever have a secondary thread that has
user-visible controls. Those of us who have C++/MFC in our MFC
recognition would never, ever do this, and we know what can go wrong; we
just don’t want to have to deal with the problems. Essentially, you do
ALL your UI interactions from the main thread of your MFC app. You do not
pop up dialogs or message boxes in a secondary thread, ever. You do not
touch any window of your UI from a secondary thread, ever. If you think
you need to do any of these things (a) you are wrong (b) you will get into
trouble and (c) there is always a way to avoid doing this. I’ve been
programming in MFC for about 15 years, and I have never needed to ASK any
of the questions you have asked, because I have made sure that the answers
never MATTERED. If you think the answer matters, your design is probably
wrong.

You do not “protect threads”, and anything you hear related to such a
concept is nonsense. The purpose of locks is to protect DATA. Threads do
not need “protection”, and I have no idea what it would mean if they did.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

7

xxxxx@gmail.com wrote:

In multicore or multiprocessor systems, thread scheduler can work on every processor at the same time. Right?

Is there a global thread queue that CPUs look up to select a thread or also thread database (or queue) is per processor as well?

There is a global thread list, although some threads in the list have an
affinity setting that limits the cores on which they are willing to run.

If it is per processor my question is, if I build a simple MFC dialog window and run it, why don’t I see the same number of window equal to my CPU’s core number. Because every core can select to run the thread that runs UI.

Your thread that is ready to run sits in the ready-to-run thread queue.
Eventually, it bubbles up to the top of the priority list. The next
core that needs something to do checks the thread queue and pulls yours,
at which point it begins running. At that time, the thread is no longer
in the ready-to-run list, so no other processor will find it.

Other question is,so, If I create a thread, do I always protect it with mutex to not be able to be run concurrently by other cores?

One thread can only run on one core at one time. That’s a fundamental
principle of the universe. Now, if you call CreateThread 8 times with
the same function, then your code can be running in 8 different
processors at once, and protection becomes a real issue.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

8

>Your thread that is ready to run sits in the ready-to-run thread queue.

Eventually, it bubbles up to the top of the priority list. The next
core that needs something to do checks the thread queue and pulls yours,
at which point it begins running. At that time, the thread is no longer
in the ready-to-run list, so no other processor will find it.

Windows7+ (or Vista+) scheduler is fancier. A READY thread is assigned a processor to execute on and is put into that processor queue (See !ready command output). A thread won’t be pulled from the per-processor list even if some other processor becomes idle. That’s the drawback of the lock-free scheduler.

9

It’s an interesting set of tradeoffs; I’ve worked on multiprocessors with
both kinds of schedulers, and in one multiprocessor system we went from a
per-core queue to a global queue because it gave better throughput on that
architecture. On another, the opposite effect was noted by the vendor of
the RTOS.
joe

>Your thread that is ready to run sits in the ready-to-run thread queue.
>Eventually, it bubbles up to the top of the priority list. The next
>core that needs something to do checks the thread queue and pulls yours,
>at which point it begins running. At that time, the thread is no longer
>in the ready-to-run list, so no other processor will find it.

Windows7+ (or Vista+) scheduler is fancier. A READY thread is assigned a
processor to execute on and is put into that processor queue (See !ready
command output). A thread won’t be pulled from the per-processor list even
if some other processor becomes idle. That’s the drawback of the lock-free
scheduler.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

10

With per-core queue, if one core gets live-locked because of runaway DPC, the threads queued to it are never getting the opportunity to run. Eventually some critical threads get stuck behind the livelocked CPU.

11

wrote in message news:xxxxx@ntdev…
> With per-core queue, if one core gets live-locked because of runaway DPC,
> the threads queued to it are never getting the opportunity to run.
> Eventually some critical threads get stuck behind the livelocked CPU.
>

That anyway would mean a broken system which is likely to bugcheck or
freeze.

The thread can be waiting behind a DPC. But you are not saying it can be
scheduled waiting behind other threads in the queue already assigned to the
same CPU or do you ?

//Daniel

12

>The thread can be waiting behind a DPC. But you are not saying it can be

scheduled waiting behind other threads in the queue already assigned to the
same CPU or do you ?

That’s what I saw in one crashdump. A bunch of threads of different priority queued on two live-locked CPUs, while other CPUs were idle.

13

All sorts of things are going to (eventually) go wrong if you have a processor that goes out to lunch at raised IRQL and never comes back.

  • S (Msft)

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Tuesday, September 04, 2012 3:41 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Thread Scheduler per processor but thread database???

The thread can be waiting behind a DPC. But you are not saying it can
be scheduled waiting behind other threads in the queue already assigned
to the same CPU or do you ?

That’s what I saw in one crashdump. A bunch of threads of different priority queued on two live-locked CPUs, while other CPUs were idle.

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer