Re: Threads - When?
Mathias Gaunard wrote:
Locking for reading is not that efficient.
Yes, even reading is undefined behaviour.
I am not trying to cause a big discussion on locking mechanisms but...
Locking is efficient if an atomic test-and-set operation is used _with_
old-fashioned kernel-mode wait-state models. This presumes that the
acquire() is satisfied most of the time. If there are times that it is
not and a wait-state has to be entered, it is not efficient, but that
would have happened anyway.
The first problem is the domain of the OS people. For example, if
there were no atomic operations like test-and-set, or even an
ALU-managed XOR to external store, there would be nothing the C++
library writer could do to guarantee safeness.
There is a proposal for adding atomic operations like this to the
language.
You cannot simply add it to the language. There must be atomic
operations in the processor that support the software. Either these
atomic operations are present, or they are not. If they are present,
then the system is ultimately relies on them to implement
synchronization. If they are not, then it should be intuitively
obvious that you are out of luck.
I suppose that if they're available on hardware they will be
used as is and otherwise they would be software emulated with mutexes.
Software mutexes, events, semaphores, etc. are all backed by atomic
operations. Even the most primitive form of spin-locking requires
atomic operations. If you ever see a paper talking about about
"lock-free" operations, quickly scan the paper for two things:
1. Use of atomic hardware instruction
2. Spinning (note that even this requires atomic reads and writes)
Once you have #2, all best are off, as spinning is an extremely
inefficient form of waiting. Kernel-mode device drivers use it often
because "they know it is ok to do so". For example, if you are
processing an Ethernet frame that just arrived over the MAC, and you
are holding a lock that another kernel-mode component needs, it might
be better for that component to simply spin and wait it out that go
through the trouble of enter a full-blow wait state.
Here is paper where author hand-waves a bit on the spinning issue. He
claims that, while a process is trying to (effectively) acquire a lock
it should "DoSomethingUseful()" or "just wait or spin".
http://www.ddj.com/dept/cpp/189401457?pgno=3
1. You cannot just "DoSomethingUseful()". Generalized software do
have tasks sitting around "waiting to be done".
2. "wait" is more like it, but processes are not human. They cannot
say, "Hey CPU..I am in a tight while loop at the moment. Could you
just not give me any quanta please? BUT!! I do not want to enter a
wait state. I am trying to process that lock-free operations work.
Just give get me off the CPU quick each time around and give my quanta
to someone else."
3. "spin" is more like it, because that is precisely what he is doing.
And if you are spinning, you are not in a wait-state, as far as the
CPU is concerned. And if you are not in a wait-state, the CPU will
allow the full-quanta. The machine will become intolerably slow.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]