[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#479952: libc6/s390 - __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.

On Mon, Oct 27, 2008 at 10:05 AM, Andrew Haley <aph@redhat.com> wrote:
>> I've seen this on-and-off again on the hppa-linux port. The issue has,
>> in my experience, been a compiler problem. My standard operating
>> procedure is to methodically add volatile to the atomic.h operations
>> until it goes away, and then work out the compiler mis-optimization.
>> The bug is almost always a situation where the lll_unlock is scheduled
>> before owner = 0, and the assert catches the race condition where you
>> unlock but have not yet cleared the owner.
> Are you sure this is a compiler problem?  Unless you use explicit atomic
> memory accesses or volatile the compiler is supposed to re-order memory
> access.  Perhaps I'm misunderstanding you.

Sorry, parsing the above statement requires knowing something about
how lll_unlock is implemented in glibc.

The lll_unlock function is supposed to be a memory barrier.

The function is usually an explicit atomic operation, or a volatile
asm implementing the futex syscall i.e. INTERNAL_SYSCALL macro.


Reply to: