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 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.  The code that the paragraph
addresses contains (shared-memory) synchronization, so code where things
don't actually run in parallel and separate (like parallel lines would
do), but where the different threads have to coordinate.

The distinction is a little fuzzy of course, because most forms of
parallelism have at least some concurrency/synchronization in them, and
good concurrent code tries to maintain parallelism where possible.
Likewise, when you look at programming abstractions for parallelism,
then these try to support splitting one piece of work into independent
parts; in contrast, concurrency abstractions try to handle threads of
execution that run concurrently and are not independent but have to

ISO C++ SG1 also uses this terminology, basically.  For example, the
latches and barriers proposals go into the Concurrency TS, whereas
parallel algorithms are in the Parallelism TS.

How would you define both categories?

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