Re: [PATCH] Fix double-checked locking in _res_hconf_reorder_addrs [BZ #19074]

[Torvald Riegel <triegel at redhat dot com>]

On Tue, 2015-10-06 at 16:33 +0200, Florian Weimer wrote:
> On 10/06/2015 04:08 PM, Siddhesh Poyarekar wrote:
> > On Tuesday 06 October 2015 06:02 PM, Florian Weimer wrote:
> >> This addresses a data race in libresolv.  The race is not entirely
> >> benign, it could cause programs to access a partially initialized
> >> ifaddrs array.
> >>
> >> I made sure this compiles on x86_64, but this code is difficult to test.
> >>
> >> A potential follow-up optimization would be to move the socket creation
> >> under the lock.  No need to create a socket if we lose the race to the lock.
> > 
> > The code needs verbose comments to describe the rationale for the
> > ordering semantics you've decided on.
> 
> Do we have documentation on the wiki for common concurrency idioms?

Not yet.  A section on the Concurrency might be a good place for that.

If you should write this page, check whether you really need the acquire
MO in the load in the critical section, or whether relaxed MO is
sufficient ;)

> It's probably best to document things that work and way, and stick to
> that, instead of using ad-hoc schemes all over the place.

I agree that it's good to follow common patterns.  Nonetheless, you
still need to say why the pattern applies, and make sure that all
readers see the pattern and can check that the pattern is applied
properly.  This can be brief -- but if people in the community feel like
they need more details in the comments, it should be provided in most
cases, I think.

>  (I think the
> code I showed is sufficiently close to the usual double-checked locking
> idiom, except that the guarded section may run multiple times.)

Are you referring to that the critical section may be entered
unnecessarily?  That is common for double-checked locking.  Or are you
referring to something else?