This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Consensus: data-race freedom as default for glibc code

On Mon, 2014-11-24 at 17:23 +0100, Florian Weimer wrote:
> On 11/24/2014 04:45 PM, Torvald Riegel wrote:
> > On Mon, 2014-11-24 at 16:25 +0100, Florian Weimer wrote:
> >> On 11/24/2014 04:23 PM, Torvald Riegel wrote:
> >>>>    >   * Parallel algorithms implemented in glibc itself will be free from
> >>>>    >     data races (as defined by C11 and its memory model) by default.
> >>>
> >>> I changed it to:
> >>> * Concurrent code in glibc is free from data races (as defined by C11
> >>> and its memory model) by default.
> >>
> >> Fine with me as well (although I think technically, this is about
> >> parallelism, not concurrency :-).
> >
> > And I disagree, that's why I changed it :)
> >
> > We don't parallelize anything in glibc.
> Ugh, we parallelize the execution of threads (unlike the old FSU threads 
> implementation).

What I meant was that there's no glibc function that actually splits
work into parallel tasks or such.  Yes we run threads concurrently, but
there's no parallel loop, fork/join parallelism, or similar in glibc.
Vector libm functions are parallelism, though.

> > How would you define both categories?
> Concurrency is non-deterministic execution of (sequential) subprograms 
> in response to external events.  Parallelism is the simultaneous, 
> interleaved execution of subprograms.  Or something like thatâbasically, 
> you can only have high-level race conditions in a concurrent 
> application,

C11 and C++11 use it differently.  For example, C11 (N1570)
"Concurrent access to the variable being initialized, even via an atomic
operation, constitutes a data race."

You could also have a look at the shared-memory synchronization
literature to see how they use the terms.

> for low-level things (covered by the C11 memory model), you 
> need parallelism.
> But I suspect this particular sub-discussion will never have a fruitful 
> outcome.

Maybe.  For glibc, I think it's best to use the terminology the C
standard uses.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]