Re: What's left for 1.1.11 release?

[Rich Felker <dalias@libc.org>]

On Tue, Jul 28, 2015 at 04:09:38PM +0200, Jens Gustedt wrote:
> Hello,
> 
> Am Montag, den 27.07.2015, 23:40 -0400 schrieb Rich Felker:
> > In principle the a_store issue affects all libc-internal __lock/LOCK
> > uses,
> 
> so this worries me since I assumed that UNLOCK had release consistency
> for the __atomic implementation.

It does. The problem is that it lacks acquire consistency, which we
need in order to know whether to wake.

> > and stdio locks too, but it's only been observed in malloc.
> > Since there don't seem to be any performance-relevant uses of a_store
> > that don't actually need the proper barrier, I think we have to just
> > put an explicit barrier (lock orl $0,(%esp) or mfence) after the store
> > and live with the loss of performance.
> 
> How about using a xchg as instruction? This would perhaps "waste" a
> register, but that sort of optimization should not be critical in the
> vicinity of code that needs memory synchronization, anyhow.

How is this better? My intent was to avoid incurring a read on the
cache line that's being written and instead achieve the
synchronization by poking at a cache line (the stack) that should not
be shared.

Rich