Re: [GSoC Project Proposal] ISO C11 threads.h implementation in GNU C Library

[Andrea Francesco Iuorio <andreafrancesco dot iuorio at gmail dot com>]

I don' t want to interfiere in this topic since i could be considered
a competitor and i want to play fair but Juan posted here its proposal
and we should give him feedbacks about it here. The discussion about
"native"/pthread implementation is usefull and interesting (
expecially for me and i vote for the pthread implementation. It is
true that introduce some overheads but with just one implementation we
can target on every pthread target using well-tested functions and we
don' t have to mantain different os-dependent code that do the same
thing in two different libraries. In my opinion this justify the
little decrese in performance ) but this shouldn' t be the place.
Excuse me if i' m sounding rude.

2014-02-27 22:48 GMT+01:00 Joseph S. Myers <joseph@codesourcery.com>:
> On Thu, 27 Feb 2014, Rich Felker wrote:
>
>> > I don't think separate implementations, with all the complications of
>> > associated architecture-dependencies and direct use of many tricky
>> > low-level glibc and Linux kernel interfaces, is something that is either
>> > reasonably maintainable, or reasonably implementable within the scope of a
>> > GSoC project.
>>
>> There is nothing architecture-dependent involved in implementing these
>> primitives. They would all be built on either existing __lll*
>> functions or direct use of atomics+futex.
>
> I don't think it's sensible to try building a complicated set of
> interfaces on those low-level interfaces for a GSoC project; debugging
> problems showing up when using them (often architecture-specific) is too
> hard compared to using the pthread_* interfaces that have been debugged
> over the course of many years.  This project was carefully chosen as
> something that is not heavily dependent on glibc internals (beyond
> namespace issues); most glibc development ideas would not be suitable for
> GSoC.
>
>> Note that POSIX specifies all synchronization primitives as full
>> barriers, while C11 has separate release/acquire semantics. This means
>> the C11 primitives have the potential to give much better performance
>> on architectures where release and acquire barrier semantics are
>> distinct.
>
> C11 threads only specify that certain operations synchronize with certain
> later operations.  In some cases this might mean lesser barriers are
> sufficient, but the operations don't have any explicit memory order
> parameters.
>
>> >  In addition, C11 threads should interact in some reasonable
>> > way with POSIX interfaces in programs that use both -
>>
>> Do you think it's wise to make a public interface guarantee that C11
>> mutex pointers can be passed to pthread mutex functions and vice
>> versa? I think this would be a big mistake; for example, if semantics
>> diverged in any way due to different interpretations, the guarantee
>> would have to be retroactively revoked.
>
> Passing pointers like that isn't possible because of the C++ tag issue
> already explained.
>
> My point is more about e.g. setuid / setgid in the presence of multiple
> threads - there should be a single set of threads, not separate sets of
> POSIX and C11 threads, with common infrastructure for doing thread
> operations on them, and doing a POSIX operation that affects a C11 thread
> should work the same way as when it affects a POSIX thread.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com



-- 
Andrea Francesco Iuorio
Student in Computer Science, Università degli Studi di Milano
andreafrancesco.iuorio@gmail.com - GPG Key