On Sat, Nov 16, 2013 at 11:41:03AM +0100, Justus Winter wrote:
> I just realized that I tested these changes *with* the
> libports_stability.patch, so the threads do not actually time out and
> so this particular code is never reached. Maybe we should defer this
> patch until Richards patch destruc
Quoting Samuel Thibault (2013-11-16 11:16:02)
> > - pthread_spin_lock (&lock);
> > - if (nreqthreads == 1)
> > + __atomic_sub_fetch (&totalthreads, 1, __ATOMIC_RELAXED);
> > + if (__atomic_sub_fetch (&nreqthreads, 1, __ATOMIC_RELAXED) == 0)
> > {
> > /*
Justus Winter, le Fri 15 Nov 2013 20:52:23 +0100, a écrit :
> @@ -224,30 +216,22 @@ ports_manage_port_operations_multithread (struct
> port_bucket *bucket,
>
>if (master)
> {
> - pthread_spin_lock (&lock);
> - if (totalthreads != 1)
> - {
> - pthread_s
ports_manage_port_operations_multithread uses two values, totalthreads
and nreqthreads, to manage the threads it creates. Previously a lock
was used to synchronize the access to them. Use atomic operations
instead.
* libports/manage-multithread.c (ports_manage_port_operations_multithread):
Use
Hi :)
youpi wrote:
> Now, there is no need for the two counters to be updated coherently,
> they are used for different reasons, and don't actually interfere. Also,
> mixing them into one int reduces the maximum number of threads to 65535,
> which is not so big.
>
> So I'd say please move to using
On 12/11/13 20:13, Samuel Thibault wrote:
> Hello,
>
> OK, I believe that'll work indeed. What really makes it work is this:
>
> Justus Winter, le Mon 11 Nov 2013 21:12:34 +0100, a écrit :
>> + /* Decrement nreqthreads. */
>> + unsigned int tc = __atomic_sub_fetch (&thread_counts, 1,
>
Hello,
OK, I believe that'll work indeed. What really makes it work is this:
Justus Winter, le Mon 11 Nov 2013 21:12:34 +0100, a écrit :
> + /* Decrement nreqthreads. */
> + unsigned int tc = __atomic_sub_fetch (&thread_counts, 1,
> + __ATOMIC_RE
Quoting Neal H. Walfield (2013-11-11 22:02:46)
> Yes, this is what I was thinking of.
Awesome :)
> I recall there being type defs for appropriate atomic types. If that
> is still the recommended approach, please update your patch
> appropriately.
Right. I knew next to nothing about the gcc atom
Yes, this is what I was thinking of.
I recall there being type defs for appropriate atomic types. If that
is still the recommended approach, please update your patch
appropriately.
The most important thing, however, is ensuring that the semantics are
preserved. That is, was the use of the value
ports_manage_port_operations_multithread uses two values, totalthreads
and nreqthreads, to manage the threads it creates.
Previously the two values were stored in two variables and a lock was
used to synchronize the access to them.
Use a single variable thread_counts to hold both values. This way
10 matches
Mail list logo
