Re: Threads - When?

Dilip wrote:


IMO, this is precisely on topic. There seems to be a lot of C++
programmers who think that they will be able to wield some special
magic to violate what I believe are fundamental principles in OS
design. I am glad we are discussing this, because, I intend to show
that that there is no magic, that there is nothing that will be done in
code to make us able to code-and-forget.

First, spin-locks, from a C++ programmers point of view, cannot be
implemented efficiently. I will get to what I mean by that in a
moment, but first, some notes about the article you posted. Jeffrey
Richter writes:

"No programmer in his right mind wants to think about thread
synchronization as he is coding his app. This is because thread
synchronization has little to do with making the program do what its
true intention is."

These two sentences prey upon what I believe is a false notion that
programmers are going to be able to avoid multi-threading issues
altogether and "just code". This is false. It is possible to build a
system were every single access to state is protected by a mutex, and
that would work, but short of that, you are going to have to do some
thinking.

He continues to write:

"Obviously, a thread that stops running is exhibiting very bad
performance. "

This is misleading. A thread that "stops running" does not have bad
performance. A thread that stops running has almost "no" performance.
Saying that the thread has "bad performance" gives the impression that
CPU cycles are being wasted, which is simply not true (in general). If
a thread is in a wait-state, then it is in that wait-state for a
reason, and the most likely reason is that, either it has nothing to
do, or it is logistically impossible for it to have been doing anything
anyway. There is a multiple-CPU situation where it is not ideal to
block if there is anything to do for a reader-writer pair, but that is
a special case.

And now to the "cannot be implemented efficiently" statement. I will
first quote what Jeffrey Richter wrote:

"It's impossible to know for sure if spinning in user mode would yield
better performance than transitioning to kernel mode, context-switching
to another thread, and returning back to user mode. It depends on how
much time the other thread needed to complete its task and this
information cannot be determined. Furthermore, instrumenting your code
in order to attempt to determine it would negatively impact
performance, which is what you're trying to improve. There is just no
way to guarantee a win with this. Also, there are many factors that
impact this: CPU make and model, CPU speed (GHz), hyper-threading,
dual-core, other threads running on the system, and so forth."

The first few words of the preceding quote is the thesis of what I have
been saying, and it something that anyone who has ever had to write a
high-performance device driver already knows. They *know* when to use
spin-locking and when not. If they do, they already know, in advance,
that it is going to be efficient. If they do not know in advance,
while designing the software, that is going to be efficient, they will
*not* use it. The *context* of the use of the spin-lock is critical
(no pun intended). People who write little user-mode spin-locks hoping
to get lucky will see their machine quickly enter rigamortis. Without
that context, without knowing that it is OK to spin, you *will* being
executing a user-to-kernel-mode transition and a context switch.

Jeffrey Richter writes:

"If the number of CPUs is 1, then Enter calls SwitchToThread before
looping around again."

And there is is. Got a guarantee, spin. No guarantee, to go kernel.
SwitchToThread goes to the kernel.

-Le Chaud Lapin-

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]