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 s
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 t
alternating between reader
> preference and writer preference with solve both writer starvation and
> writer starvation:
> - [1] page 12
> - [2] slides 62..63
Turning on writer preference doesn't help if recursive rdlocks are
allowed, which POSIX does.
> Torvald Rie
On Fri, 2017-01-06 at 00:11 +0100, Bruno Haible wrote:
> Torvald Riegel wrote:
> > > The problem here is: it's a unit test. If it fails, I don't want to search
> > > for bugs in the condition variable subsystem, semaphore subsystem, AND the
> > > lock subsys
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
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
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
On Thu, 2017-01-05 at 22:09 +0100, Bruno Haible wrote:
> Torvald Riegel wrote:
> > > Can you give line numbers, please? lib/glthread/lock.c and
> > > lib/glthread/cond.c
> > > are large files. If you have found bugs there, *of course* I want to have
> > >
On Thu, 2017-01-05 at 19:42 +0100, Bruno Haible wrote:
> Torvald Riegel wrote [in private email, should have CCed bug-gnulib]:
>
> [about the use of a lock in 'struct atomic_int' in test-lock.c:]
>
> > > The delivered code, with a lock, is correct, how
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 concurrentl
On Thu, 2017-01-05 at 20:15 +0100, Bruno Haible wrote:
> Torvald Riegel wrote:
> > I found two bugs just by briefly scanning through the current
> > lib/glthread/lock.c. As a hint, I'll just mention double-checked
> > locking and order of destruction. And skippin
On Thu, 2017-01-05 at 20:30 +0100, Bruno Haible wrote:
> Torvald Riegel wrote:
> > IMHO, gnulib synchronization primitives should simply move towards the
> > semantics chosen by C++11 and more recent (if you dislike C++ for some
> > reason, just use the C++ semantics applied
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
understand what this does not
13 matches
Mail list logo
