C++ memory model for concurrency and publicly available compiler

[Herb Sutter]

Quick update: Bill and Doug, I'm still very interested in getting a copy
of this draft paper Doug quoted (any news on that?) but I also
discovered more info yesterday about our product (VC++ 2005 beta) I
thought I should share:

Our Whidbey C++ compiler apparently actually already implements (at
least something close to) the proposal you folks sketched for a memory
model for concurrency for C++ -- e.g., the lock-free producer/consumer
stock quote example in Andrei's evening talk works correctly with the
stock char* marked volatile (this is new in this release, it is not a
feature supported in the existing VC++ 2003 release). I hadn't paid
attention to this part of the product until your presentation caused me
to start digging around. Note that here I mean Whidbey C++ targeting
native mode -- the CLR and jitters still seem to have something a little
looser on the managed mode side. I know that the OS team has already
implemented some lock-free data structures, and I'm following up further
on that (e.g., I'm not sure whether they're internal structures or a
facility that's externally available to user code).

Anyway, one upshot is that your group should be able to actually
download a free beta compiler right now that implements the (or at least
"a") memory model for concurrency and lock-free programming very similar
to what you described. I blogged about where to get the download at
http://blogs.msdn.com/hsutter/archive/2004/09/04/225736.aspx .

Thanks,

Herb


>-----Original Message-----
>From: Herb Sutter
>Sent: Saturday, October 30, 2004 9:30 PM
>To: 'Doug Lea'; pugh at cs.umd.edu
>Cc: Andrei Alexandrescu; Hans Boehm; Doug Lea; Kevlin Henney; Maged
>Michael; Ben Hutchings
>Subject: RE: Threads: first milestone completed
>
>Re paper: I would very much like to see this paper -- can I please get
a
>copy? I am interested in getting the key expert(s) within Microsoft
looking
>at this topic as part of understanding where we are in both the JVM and
the
>CLR w.r.t. this topic.
>
>Also, is there any known existing practice in C++ compilers? (I have
yet to
>ask about my own group's product.)
>
>If there is a clear best answer here then ideally everyone would
implement
>it essentially the same way. That would be great for users.
>
>Herb
>
>
>>-----Original Message-----
>>From: Doug Lea [mailto:dl at cs.oswego.edu]
>>Sent: Saturday, October 23, 2004 5:10 AM
>>To: Herb Sutter
>>Cc: Andrei Alexandrescu; Hans Boehm; Doug Lea; Kevlin Henney; Maged
>>Michael; Ben Hutchings; pugh at cs.umd.edu
>>Subject: RE: Threads: first milestone completed
>>
>>> As a start, the Ecma-335 standard for CLI (same as ISO standard
CLI),
>>> Partition I section 12.6, which is about a memory model for CLI
>>
>>Herb -- Here's a paste of the discussion of CLI MM in upcoming POPL
>>paper "The Java Memory Model" by Jeremy Manson, William Pugh, and
>>Sarita Adve
>>
>>    The ECMA specification for the Common Language Infrastructure
>>    (CLI) provides a memory model [7]. However, it is vague and
>>    informal; as a result it seems impossible to determine whether
>>    that model allows or disallows behaviors such as shown in Figures
>>    4, 2, 5 and 6. It is also worth noting that some of the Microsoft
>>    engineers have published articles [6] in which they claim that the
>>    CLI specification is too relaxed, and that they have written code
>>    as part of Microsoft s core libraries that won t work according to
>>    the ECMA spec.
>>
>>Bill -- Can you make this paper available? I don't see a link to it
>>anywhere.
>>
>>-Doug