[cpp-threads] Memory model counterproposal: synchronizationoperations

[Boehm, Hans]

At least part of the reason for the preceding silence is that
we're still thinking/reading.  I don't think we currently have a
way to describe the memory model that can deal well with
with unordered atomic operations.  Or for that matter one that
could deal with a pthread_mutex_lock() that has only "acquire"
semantics.  I think there is a consensus that we need to support
both.

As to the present proposal, I think the argument for introducing
a stronger volatile syntax is that:

1) There exist mountains of code that use double-checked
locking or similar hacks.  (Some major vendors recommended
it until very recently.  And there appear to be many cases
in which it is critical to performance.  Thus "don't do that"
is not a real option.)

2) This code is broken, but we need to provide an easy path to
fix it.

3) __async volatile (or some alternative set of keywords)
would make this easy, and would allow basically the same
technique to work across C++, Java, and potentially C.

In my view, it's not yet clear whether a library-only solution
gets close enough to this that it's not worth bothering with
the keyword.  I'm concerned that it will at least result in
completely different idioms for C, C++, and Java.  (I think
C# and Java will end up similar.)  In my view, that would
be highly undesirable, since I think our primary goal should be
to make it easier to teach people to write reliable multithreaded
code.  And most of those people will need to deal with more
than one language.

But I would be very happy to postpone this
decision until it's clear whether this concern is justified.
If the only difference is the declaration syntax for the
flag variable in double-checked locking, and we can make that
work across C and C++, then I'm happy with a library-only
solution.

Hans


> -----Original Message-----
> From: 
> Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk 
> [mailto:Cpp-threads_decadentplace.org.uk-bounces at decadentplace
> .org.uk] On Behalf Of Nelson, Clark
> Sent: Thursday, May 26, 2005 10:11 AM
> To: cpp-threads at decadentplace.org.uk
> Subject: [cpp-threads] Memory model counterproposal: 
> synchronizationoperations
> 
> 
> It is well that it is already acknowledged (as measured by 
> the introduction of __async) that a simple access to a 
> volatile object can not be made into a synchronization 
> operation (syncop), as Intel would have to firmly oppose such 
> a proposal.
> 
> But given that no existing syntax can reasonably be mapped to 
> a syncop, we don't see the point of adding a new type 
> qualifier, and defining accesses to such objects as syncops. 
> Most especially considering that there will in any event be 
> library functions that imply syncops.
> 
> So we propose that only library functions (to be specified) 
> will imply syncops.
> 
> -- 
> Clark Nelson		Vice chair, J16 (ANSI C++ standard committee)
> Intel Corporation
> clark.nelson at intel.com
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decad
entplace.org.uk