[Bug nptl/16657] Lock elision breaks pthread_mutex_destroy

["jmbnyc at gmail dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=16657

--- Comment #20 from Jeffrey M. Birnbaum <jmbnyc at gmail dot com> ---
Let me elaborate as to what I see and you can perhaps help me determine if it
is the same (or similar) issue reported here. If not, then I will submit a
separate bug report (TIA).

here is the an outline of the code being used:

// assume that construction result in pthread_mutex_trylock where an 
// internal isLocked variable is set to true if the the call returns 0.

mutex_lock::try_lock_guard guard(_db_lock);
if (!guard.isLocked())
{
   // assume timer is returning elapsed time in seconds
   while(!guard.isLocked() && timer.elapsedTime() < 1.0)
   {
      millisleep(1);
      guard.lock(); // will call try_lock and set locked flag inside guard
   }
}

When I run this code compiled with gcc 4.8.2 on my Linux 3.12.8 system (with
Haswell processor) I observe that if try_lock fails to get the lock then it
never succeeds to to get the lock. And I know (from tracing) that the lock has
been released during the time that this code is executing (and that other
thread that does release does not attempt to get the lock more than once a
second).

At first I thought this might be a compiler bug where isLocked() is not being
reevaluated each time in the loop but then I came across this report which
makes me suspect it is an elision bug not a compiler bug. If it were a compiler
bug then I would be quite unnerved and would stop using gcc 4.8.2.

Does this help?

-- 
You are receiving this mail because:
You are on the CC list for the bug.