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

Discussion in 'C++' started by Chris Thomasson, Sep 3, 2006.

  1. [...]

    <> wrote in message
    > kanze wrote:
    >> 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?
    Chris Thomasson, Sep 3, 2006
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. eridgway

    Portal Starter Kit - Security Concerns

    eridgway, Sep 9, 2004, in forum: ASP .Net
    Sep 10, 2004
  2. PKJ
    Victor Bazarov
    Oct 22, 2004
  3. memory related concerns

    , Jun 22, 2006, in forum: C Programming
  4. Joshua Maurice
    Alexander Terekhov
    Sep 4, 2010
  5. Srijayanth Sridhar

    Memory concerns wrt garbage collection etc

    Srijayanth Sridhar, May 28, 2008, in forum: Ruby
    Robert Klemme
    Oct 24, 2008

Share This Page