This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: -fno-tree-cselim not working?


From: Ian Lance Taylor <iant@google.com>
Date: 25 Oct 2007 21:31:56 -0700

> Samuel Tardieu <sam@rfc1149.net> writes:
> 
> > int
> > trylock()
> > {
> >   int res;
> > 
> >   res = pthread_mutex_trylock(&mutex);
> >   if (res == 0)
> >     ++acquires_count;
> > 
> >   return res;
> > }
 ...
> Code like needs to use volatile or explicit memory barriers.

I totally disagree with you, and I think POSIX does too.

Threaded programming is hard enough as it is.

What's the point of the lock if a test on whether we've obtained it or
not can't be used to conditionalize code execution?

Any write to memory is a globally visible side effect, and even
ignoring theading issues I bet similar cases can be constructed
involving signals that behave equally unexpectedly and should not
require bogus memory barriers or volatile.

I'm not sure people realize the true ramifications of this suggested
"fix".  It is rediculious, by any measure.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]