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
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 subsystem. I want the test to rely essentially only on the lock
> > subsystem.
>
> locks are the wrong mecha
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
>
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
> > them fixed.
>
> I can understand both points. However, I'd suggest that you first try
> to find them (or
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, however, right?
> >
> > Not quite, unfortunatel
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
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 skipping destruction is of course
> > not
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 to C11; C is lacking be
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
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 to C11; C is lacking behind
> in terms of preciseness of the specification).
>
> Of c
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 skipping destruction is of course
> not correct in the general case either (unless I'm misreading
> lib/
Pavel Raiskup wrote:
> Thanks. Minor report is that gl_thread_join() is not handled properly for
> joined thread statuses.
>
> This leads to situation that Koji build system tries to gently terminate
> the build first (after two days) ... which (sometimes?) leads to successful
> 'test-lock' run i
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, however, right?
>
> Not quite, unfortunately, because locks do not make any guarantees
> regarding fairness. Th
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
Thanks. Minor report is that gl_thread_join() is not handled properly for
joined thread statuses.
This leads to situation that Koji build system tries to gently terminate
the build first (after two days) ... which (sometimes?) leads to successful
'test-lock' run in the end and the build succeeds
Pavel Raiskup wrote:
> I still see infinite hang on ppc64le (sometimes), as discussed in [1]. It
> looks like starvation of writers in test_rwlock().
>
> Could we set PTHREAD_RWLOCK_PREFER_WRITER_NP (in test-lock.c) to avoid
> those issues?
Here's what I'm pushing.
You were right with your intu
When a gnulib testdir is configured with
--enable-threads=pth --with-libpth-prefix=...
the test test-thread_create crashes. The reason is that most Pth functions
crash (and pth_self() returns the value NULL) if pth_init() has not been
called.
This patch fixes the gnulib 'thread' module according
18 matches
Mail list logo
