Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 28 Jul 2015 10:18:03 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: What's left for 1.1.11 release?

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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.