On 01/06/2017 04:22 AM, Torvald Riegel wrote:
> 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?
I know a bit about the 2011 models, as well as the JMM. I do not know
t
On Fri, 2017-01-06 at 15:08 +0100, Bruno Haible wrote:
> Torvald Riegel wrote:
> > What are the rwlock users, actually? A web search for gl_rwlock_t seems
> > to only turn up lock.h, but no users (unlike gl_lock_t, for example).
>
> You're right, there are no users so far. But there may be in the
On Fri, 2017-01-06 at 15:25 +0100, Bruno Haible wrote:
> Torvald Riegel wrote:
> > > The rwlock writer starvation problem is not solved by throttling to a
> > > fixed
> > > percentage of CPU time: If every reader thread spends 10% of its time
> > > with the
> > > rwlock held, it will work fine wi
On Fri, 2017-01-06 at 14:17 +0100, Bruno Haible wrote:
> I asked:
> > > So, what is the fairness-ensuring mechanism that will make use of locks
> > > starvation-free? Can it be *easily* and *portably* put in place?
>
> Textbooks from university teacher state that alternating between reader
> prefe
Torvald Riegel wrote:
> > The rwlock writer starvation problem is not solved by throttling to a fixed
> > percentage of CPU time: If every reader thread spends 10% of its time with
> > the
> > rwlock held, it will work fine with 4 CPUs, but it will hang with 24 CPUs.
>
> Well, obviously, you need
Torvald Riegel wrote:
> What are the rwlock users, actually? A web search for gl_rwlock_t seems
> to only turn up lock.h, but no users (unlike gl_lock_t, for example).
You're right, there are no users so far. But there may be in the future:
Gnulib occasionally grabs some piece of code from glibc
I asked:
> > So, what is the fairness-ensuring mechanism that will make use of locks
> > starvation-free? Can it be *easily* and *portably* put in place?
Textbooks from university teacher state that alternating between reader
preference and writer preference with solve both writer starvation and
w
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++ spe
On Thu, 2017-01-05 at 22:20 +0100, Kamil Dudka wrote:
> On Thursday, January 05, 2017 21:13:07 Bruno Haible wrote:
> > Torvald Riegel wrote:
> > > IMO, users of reader-writer locks should treat them as a
> > > mutual-exclusion mechanism. That is, a mechanism that just ensures that
> > > two critic
On Fri, 2017-01-06 at 00:43 +0100, Bruno Haible wrote:
> Torvald Riegel wrote:
> > whenever you have a bounded amount of parallel
> > work, you don't care what gets executed first.
> > ...
> > You control the incoming work. ...
> >
> > Look at your unit test, for example. Typically, the transacti
Torvald Riegel wrote:
> whenever you have a bounded amount of parallel
> work, you don't care what gets executed first.
> ...
> You control the incoming work. ...
>
> Look at your unit test, for example. Typically, the transactions would
> be the result of some input operation, not spawned as fas
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 t
On Thursday, January 05, 2017 21:13:07 Bruno Haible wrote:
> Torvald Riegel wrote:
> > IMO, users of reader-writer locks should treat them as a
> > mutual-exclusion mechanism. That is, a mechanism that just ensures that
> > two critical sections will not execute concurrently (except if both are
>
On Thu, 2017-01-05 at 21:13 +0100, Bruno Haible wrote:
> Torvald Riegel wrote:
> > IMO, users of reader-writer locks should treat them as a
> > mutual-exclusion mechanism. That is, a mechanism that just ensures that
> > two critical sections will not execute concurrently (except if both are
> > re
Torvald Riegel wrote:
> IMO, users of reader-writer locks should treat them as a
> mutual-exclusion mechanism. That is, a mechanism that just ensures that
> two critical sections will not execute concurrently (except if both are
> readers, of course), so at the same time. It is also important to
15 matches
Mail list logo
