Re: C++ Threads, what's the status quo?
Zeljko Vrba wrote:
On 2007-01-14, James Kanze <james.kanze@gmail.com> wrote:
Just a nit, but on Intel 32 bits, the operation is only atomic
if the decl instruction is preceded by a lock prefix. One
You're right, i've re-checked the manuals. The LOCK# signal is asserted
automatically only for the xchg reg,mem instruction. Other instructions
require an explicit lock prefix.
And I'd forgotten that it even did it then. It didn't when I
wrote my OS for the 8086.
Not according the the specifications I've seen. Even the
I've wrongly generalized automatic locking from xchg to all instructions.
You can't define atomic access until you have a memory model.
Hmm, I view atomic access as something independent of memory
model. Atomicity is well-defined concept ("completion of
operation without interruption") that is generally applicable.
Not really. The problem is what other threads (running on other
processors) see.
What does it mean, otherwise?
Do databases have a memory model? (I'm referring to ACID transactions).
[I'm trying to make a point that one does not need memory model to
understand the notion of atomicity. Maybe I'm wrong, maybe databases
*do* define something similar, although with another name.]
Databases do have a memory model, in a way, although it's not
main memory. They definitely do define who sees what when;
other users don't see my modifications, for example, until I
commit.
There are two open issues: What about other accesses to the
variable? You typically need some sort of special instructions
in both threads for modifications in one thread to be
necessarily visible in another. (Under Posix, for example, ALL
Yes, some support for memory barriers and possibly cache synchronization.
The latter is automatically handled at least on x86. (Is there a modern
machine that doesn't handle it automatically?)
It depends on what you consider "cache", I think. Modern
processors pipeline a lot of accesses internally, and reorder
accesses even before going to what is classically considered
"cache".
accesses to x must be protected by the lock.) And the other is
other memory; do you expect all modifications to y which occured
before this point to be effective, or not? (If not, it's of
dubious utility.)
Yes, I do expect that.
Well, that's more than what one normally understands by
"atomic".
OK, neccessary features are piling up (I haven't yet even mentioned compare-
and-exchange instructions), and it seems that all of this functionality
(atomic access) can be provided by functions, with a bit more inconvenient
syntax. Except for memory reads and writes. I hope you don't propose to
use functions like '_atomic_read(&var)' instead of writing 'var' whenever
this is needed ;) For pure memory reads and writes, 'volatile' might already
serve well.
It might, but it doesn't.
But for all of the above to be of any use, we still need to somehow be
able to specify that a sequence of statements is to be executed in an
exact order as written..
No. That's too constraining. What's needed is the possibility
to say that everything which precedes becomes visible before
anything that follows.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]