By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,307 Members | 1,950 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,307 IT Pros & Developers. It's quick & easy.

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

P: n/a

<wk****@yahoo.comwrote in message
kanze wrote:
>wk**** 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

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


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

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:
(read all, BTW I was SenderX)

Here is some of my quick thoughts on the subject:

I hope the memory model c++ finally go with is compatible with lock-free
reader patterns:
(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:
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
(portable lock-free data-structures)

Any constructive thoughts?
Sep 3 '06 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.