Some quick c++ memory-model concerns...

[Chris Thomasson]

[...]

(e-mail address removed) wrote: . [...]
An important consideration is being able to the guarantee order
some set of writes becomes visible to other threads. But it's
part of the larger problem of the memory model in general.

I talked about that in the part you didn't quote. When
I say "observable read/write" I guess I need to clarify this
means like a read/write of a volatile variable. I think the
Standard does require that the order (as determined by
sequence points) be preserved.

volatile has nothing to do with the memory model... Well, except in
Microsoft...

http://groups.google.com/group/comp.programming.threads/msg/52fbe7472d229061?hl=en

http://groups.google.com/group/comp...d64d/52fbe7472d229061?&hl=en#52fbe7472d229061

I hope that volatile does not become so strict that is rendered useless...

The definition of "observable behavior" in the current
Standard should be fleshed out, but I think it will
always be somewhat open-ended. Maybe the
comparison is with the number of bits in an int,
with a minimum but no max, just a requirement
that you say what it is. If a compiler assets that
it supports multi-threading of a given type, all
threads must "properly see" each others
observable reads/writes.

I would not use that compiler... That sounds more strict than Java memory
model:

http://groups.google.com/group/comp.programming.threads/msg/5c24e02f54919230?hl=en

http://groups.google.com/group/comp.programming.threads/msg/a730da4289ee4e7f?hl=en

:O

If a compiler targets
a multi-core processor without implicit
cache synchronization,
Huh?


the doc should say when/
whether it's going to generate the explicit
cache flushes/invalidates for the cores to
pass data between themselves.

Ahhh... Okay...

Anytime somebody talks about the cache wrt the memory model... Well:

http://groups.google.com/group/alt.winsock.programming/msg/db0139360ffbf4e2


http://groups.google.com/group/comp.programming.threads/msg/423df394a0370fa6


http://groups.google.com/group/comp...6c5581240e/423df394a0370fa6?#423df394a0370fa6
(read all, BTW I was SenderX)





Here is some of my quick thoughts on the subject:



http://groups.google.com/group/comp.programming.threads/msg/ca2f1af4552233df

http://groups.google.com/group/comp...son+memory+fences+x86&rnum=2#08d850d47125a2b8





I hope the memory model c++ finally go with is compatible with lock-free
reader patterns:

https://coolthreads.dev.java.net/servlets/ProjectForumMessageView?forumID=1797&messageID=11068

http://groups.google.com/group/comp.programming.threads/msg/a730da4289ee4e7f
(Yikes! Not good; for me at least...)


I have grave concerns about the negative impact that "overly
strict/paranoid" memory models can have on advanced thread synchronization
techniques. IMHO, it would be really neat for C++ to have efficient and
flexible support for this kind of stuff:


http://groups.google.com/group/comp...e3ba7?lnk=gst&q=vzOom&rnum=1#bc1506fb6d0e3ba7


I am looking forward to see what c++ come up with; One quick piece of advice
: Please don't let c++ memory model turn into a behemoth; think of poor
java... I can't implement my vZOOM library on Java. It could be done with
Java volatiles, however IMHO it would simply be big a waste of my time and
energy. Java would force my reader threads to use memory barriers during
their various searching activities'. Why bother...?

Therefore, I really hope that C++ will allow me to be in complete and total
control wrt the memory barriers that any of my code uses.



Thank you all for your time.

--
Chris Thomasson
http://appcore.home.comcast.net/
(portable lock-free data-structures)




Any constructive thoughts?