Re: glibc 2.23 --- Starting soft/slush freeze

[Torvald Riegel <triegel at redhat dot com>]

On Tue, 2016-01-12 at 10:36 -0200, Adhemerval Zanella wrote:
> 
> On 12-01-2016 10:25, Torvald Riegel wrote:
> > On Mon, 2016-01-11 at 18:52 -0200, Adhemerval Zanella wrote:
> >> Hi all,
> >>
> >> At stated in a previous message we are now in soft/slushy freeze mode. 
> >> Please do not commit new features other than the ones already reviewed.
> >> If your new feature still needs review and was not listed in the releases 
> >> wiki as a blocker feature [2] it is unfortunately too late. Please defer 
> >> to glibc 2.23 when it opens.
> > 
> > The barrier patch has been reviewed by Paul Murphy and tested by him on
> > Power.  Paul said he might prefer if someone else reviewed it too,
> > though.  Can this be considered reviewed then?
> 
> I will also check it on aarch64/arm today and I also would like to see it
> on 2.23.

Thanks!

> The only bit I am not sure is the sparc stated by you it might
> broke on newer implementation. Do you think we can get sparc parts done
> and tested by the end of the week?

The only thing that makes sparc different is that pre-v9 sparc32 has no
real support for atomics.  The atomic operations we have are supported,
but CAS or other read-modify-write operations are only atomic within a
process (the hardware only has a test-and-set, so things need to be
lock-based essentially).

For all but pre-v9 sparc, I'd just use the new barrier implementation.
For pre-v9 sparc, I could try to hack up a version that uses an internal
lock for all the read-modify-write atomic ops used by the new barrier
implementation.  But I can't test this.

Dave, could you take care of adapting to pre-v9 sparc?

It also feels like we might need a better process to handle such pre-v9
sparc issues.  It comes up whenever we change concurrent code that is
supposed to work in a process-shared setting (it will come up for
condvars again).  Any suggestions?

I think one relatively clean way to support pre-v9 sparc on
process-shared was if we could set/unset a lock that is to be used for
subsequently executed atomic operations.  The set/unset would be a noop
for all but pre-v9 sparc.  On pre-v9 sparc, we could put this address
into a thread-local variable, and have the atomic RMW ops check whether
such a lock is set or not; if it is, it will be used instead of one of
the 64 per-process locks used for non-process-shared atomics.
This way, we probably wouldn't need custom pre-v9 sparc code anymore.
Performance may be somewhat slower, but it will be slower anyway due to
having to use a lock in the first place instead of using a comparatively
light-weight native atomic operation.
Thoughts?

> > 
> > Also, what about the list of desirable features?  I had assumed they are
> > candidates for late commits too but will, unlike blockers, not block the
> > release.
> > 
> 
> I see only the new barrier and condvar implementation as the desirable
> features on this release. From your previous messages I see that condvar
> is still showing some issues with your internal tests, so I take we might
> delay to 2.24 (correct me if I am wrong).

I'm behind schedule on the condvar fix, but I could try to finish it
this week too.  Would this make the new condvar acceptable for 2.23?
I don't want to rush this, but I worry about delaying to 2.24, still not
getting any reviews, and being in the same position when the 2.24
release comes around.
Are there volunteers who would be willing and able to review the new
condvar provided the fix gets posted upstream end of this week?