bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: read-write locks


From: Torvald Riegel
Subject: Re: read-write locks
Date: Fri, 06 Jan 2017 13:22:38 +0100

On Thu, 2017-01-05 at 13:19 -0800, Paul Eggert wrote:
> On 01/05/2017 12:47 PM, Torvald Riegel wrote:
> > If gnulib really wants to make concurrency simpler, than it should look
> > at higher-level abstractions first.  Especially parallelism.  But maybe
> > it should then just wait for what C++ specifies, or contribute to that
> 
> I'm afraid this overestimates the amount of development resources we
> have. Gnulib is contributed to only fitfully, and it mostly consists of
> reasonably simple portability hacks. It has to be that way, otherwise
> package developers won't understand and trust it. It's not a suitable
> place to do concurrency research.
> 
> Concurrency with shared memory is a hard problem, and the C++ (and C)
> folks have messed it up for decades. Although they may get something
> reasonable eventually, in the meantime Gnulib will probably prefer to
> limp along with something on the safer side of the axis.

I'm not quite sure what you are trying to say.

First, are you familiar with what C++ has put out recently (eg, parallel
algorithms in the C++17 draft?).  Are you familiar with the memory model
introduced in C11 and C++11?
Second, C and C++ are supposed to be close to the hardware.  Do you
dislike that?  If not, what would you have done differently?  (Besides
trying to get something like the memory model specified much earlier?)

I'd agree regarding the concurrency research, but I'd see that as reason
to not try to deviate from the semantics and the overall design of the
synchronization primitives that POSIX / C provide to you -- in
particular if that becomes nontrivial.  Is that what you wanted to say?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]