Re: Fixing multithreaded set*id() AS-safety

[Rich Felker <dalias@libc.org>]

On Sat, Dec 20, 2014 at 09:48:16AM +0100, Jens Gustedt wrote:
> Hello
> 
> Am Freitag, den 19.12.2014, 22:39 -0500 schrieb Rich Felker:
> > Neither approach is really attractive. Strategy 1 feels less hackish
> > and more elegant (it actually makes the pthread_create code more
> > elegant than it is now by having fewer special cases), but the cost
> > feels wasteful. Strategy 2 is ugly but has the ugliness isolated to
> > synccall.c (the internals for set*id()) where it doesn't interact with
> > other parts of the code in any significant way.
> > 
> > Any opinions on which way we should go? I'll probably hold off to do
> > any of this until the next release cycle (or maybe even later), but I
> > want to go ahead and start thinking about and discussing it.
> 
> I am much more in favor of version 2 or something equivalent, because
> it keeps the complexity where it belongs. As our implementation is
> currently, all changes to pthread_create would equally impact
> thrd_create.

I'm open to your view, but I don't think it follows from your
reasoning. Strategy 1 does not really add complexity to
pthread_create. It makes fewer special cases in pthread_create I
think. In effect what it's doing is just making the method of blocking
thread creation AS-safe.

Strategy 2 does add some code to pthread_create, but it just looks
like:

if (libc.block_new_threads) __wait(&libc.block_new_threads, 1, 1);

or similar. This mechanism could also be used by dlopen to block new
threads, freeing pthread_create from having to touch the __acquire_ptc
lock it does now, but since this eliminates the ability for dlopen to
wait for all threads to exit pthread_create, it would have to assume
all threads are currently in pthread_create and might be about to
create a new thread, and would thus have to pre-allocate twice the
needed amount of TLS. I'm not sure that would be a good trade-off...

Rich