[cpp-threads] Failed compare-and-swap

[Nick Stoughton]

On Tue, 2007-07-31 at 11:36 -0700, Herb Sutter wrote:
> Is Nick Stoughton on this list, seeing this thread? Cc'ing him FHI, he's our main POSIX connection.
> 
> BTW, Nick, if we want to look at 9945, am I correct that http://www.unix.org/version3/iso_std.html which has an HTML-ized 9945-2003 is authoritative for the most recent published version? And is there anything yet-unpublished but more recent (like a working draft or a CD) we should look at if we're interested in this?
> 

For 9945, the FCD ballot document is the most recent draft. You can get
this at:
http://www.open-std.org/jtc1/sc22/open/n4217.pdf

This is an FCD, which means that any and all National Body comments will
be gratefully received and considered. So, this is your one shot at
fixing pthread_mutex_trylock, if it is indeed broken!

I'll need to research the issue a little before I can give you any sort
of authoritative answer.

Can someone tell me how to get onto cpp-threads (and where to see the
archive)?
-- 
Nick 
> 
> Summarizing this subthread:
> 
> I wrote:
> > > > Sorry if the answer is obvious: What are some cases where a failed
> > trylock
> > > > needs ordering semantics?
> 
> Alexander wrote:
> > > Nothing portable under ISO/IEC 9945.
> > >
> > > "Unless explicitly stated otherwise, if one of the above functions
> > > returns an error, it is unspecified whether the invocation causes
> > > memory to be synchronized."
> > >
> > > pthread_mutex_trylock() doesn't fall under "explicitly stated
> > otherwise".
> 
> Paul wrote:
> > Sounds like we need to make sure that we should either define CAS to
> > have two modes of "success", or to get CAS to explicitly state
> > otherwise
> > should it ever be added to ISO/IEC 9945.  Might be nice to get the
> > pthread_mutex_trylock() primitive to be added to the list of
> > "explicitly
> > stated otherwise" primitives, but that doesn't sound like a short-term
> > project.  ;-)
>