unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer via Libc-alpha <libc-alpha@sourceware.org>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH 2/2] manual: Document __libc_single_threaded
Date: Thu, 21 May 2020 16:03:05 +0200	[thread overview]
Message-ID: <87d06x75d2.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <419c660c-1e1b-46e7-aafc-8deadb1a9767@linaro.org> (Adhemerval Zanella's message of "Thu, 21 May 2020 10:58:37 -0300")

* Adhemerval Zanella:

> On 21/05/2020 10:44, Florian Weimer wrote:
>> * Szabolcs Nagy:
>> 
>>> The 05/21/2020 10:15, Adhemerval Zanella wrote:
>>>> On 21/05/2020 10:09, Szabolcs Nagy wrote:
>>>>> The 05/21/2020 09:50, Adhemerval Zanella via Libc-alpha wrote:
>>>>>> On 20/05/2020 15:12, Florian Weimer via Libc-alpha wrote:
>>>>>>
>>>>>>> +@smallexample
>>>>>>> +if (__libc_single_threaded)
>>>>>>> +  atomic_fetch_add (&reference_count, 1, memory_order_relaxed);
>>>>>>> +else
>>>>>>> +  atomic_fetch_add (&reference_count, 1, memory_order_acq_rel);
>>>>>>> +@end smallexample
>>>>>>
>>>>>> Shouldn't the access to __libc_single_threaded be atomic itself
>>>>>> (at least with relaxed semantic)?
>>>>>
>>>>> not if we guarantee that this object can only be
>>>>> written while the process is single threaded.
>>>>>
>>>>> (e.g. an exiting detached thread cannot update it
>>>>> even if only one thread left.. because that may
>>>>> concurrently read it)
>>>>>
>>>>
>>>> OK, so I think we should outline that atomic operations are not required 
>>>> to acess this object and that once __libc_single_threaded is set 0 it will 
>>>> continue to indicate non-single thread even thread are jointed or detached 
>>>> thread finishes.
>>>
>>> what's wrong with pthread_join updating it?
>> 
>> It's tricky do it correctly if there are two remaining threads, one of
>> them the one being joined, the other one a detached thread.  A
>> straightforward implementation merely looking at __nptl_nthreads before
>> returning from pthread_join would not perform the required
>> synchronization on the detached thread exit.
>
> Couldn't we accomplish by making __libc_single_threaded count the total
> number of threads and making pthread_create/pthread_exit/detach exit
> atomically updating it?

We already have __nptl_nthreads as a global thread count, but it is
currently decremented too early (on the exiting thread).  As I tried to
explain, we cannot decrement it on the exiting thread itself because it
would not give us the desired synchronization, particularly not with any
kernel actions that happen afterwards.

Thanks,
Florian


  reply	other threads:[~2020-05-21 14:03 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20 18:12 [PATCH 0/2] Add __libc_single_threaded Florian Weimer via Libc-alpha
2020-05-20 18:12 ` [PATCH 1/2] Add the __libc_single_threaded variable Florian Weimer via Libc-alpha
2020-05-21 13:07   ` Szabolcs Nagy
2020-05-21 13:16     ` Florian Weimer via Libc-alpha
2020-05-21 13:26       ` Szabolcs Nagy
2020-05-20 18:12 ` [PATCH 2/2] manual: Document __libc_single_threaded Florian Weimer via Libc-alpha
2020-05-21  7:52   ` Michael Kerrisk (man-pages) via Libc-alpha
2020-05-21 12:17     ` Florian Weimer via Libc-alpha
2020-05-21 11:18   ` Szabolcs Nagy
2020-05-21 12:16     ` Florian Weimer via Libc-alpha
2020-05-21 12:50   ` Adhemerval Zanella via Libc-alpha
2020-05-21 13:09     ` Szabolcs Nagy
2020-05-21 13:15       ` Adhemerval Zanella via Libc-alpha
2020-05-21 13:30         ` Szabolcs Nagy
2020-05-21 13:44           ` Florian Weimer via Libc-alpha
2020-05-21 13:58             ` Adhemerval Zanella via Libc-alpha
2020-05-21 14:03               ` Florian Weimer via Libc-alpha [this message]
2020-05-22 10:01             ` Szabolcs Nagy
2020-05-22 10:05               ` Florian Weimer via Libc-alpha
2020-05-22 10:54                 ` Szabolcs Nagy
2020-05-22 11:08                   ` Florian Weimer via Libc-alpha
2020-05-22 15:07                   ` Rich Felker
2020-05-22 16:14                     ` Rich Felker
2020-05-22 16:36                       ` Adhemerval Zanella via Libc-alpha
2020-05-22 17:02                       ` Florian Weimer via Libc-alpha
2020-05-22 17:18                         ` Florian Weimer via Libc-alpha
2020-05-22 17:28                         ` Rich Felker
2020-05-22 17:40                           ` Florian Weimer via Libc-alpha
2020-05-22 17:49                             ` Rich Felker
2020-05-22 19:22                               ` Szabolcs Nagy
2020-05-22 19:53                                 ` Rich Felker
2020-05-23  6:49                                   ` Szabolcs Nagy
2020-05-23 16:02                                     ` Rich Felker
2020-05-25  8:08                                       ` Florian Weimer via Libc-alpha
2020-05-25 17:21                                         ` Rich Felker
2020-05-27 11:54                                           ` Florian Weimer via Libc-alpha
2020-05-27 15:36                                             ` Rich Felker
2020-06-03 15:00                                               ` Florian Weimer via Libc-alpha
2020-06-03 17:11                                                 ` Rich Felker
2020-05-25  8:08                                       ` Florian Weimer via Libc-alpha
2020-05-21 13:56           ` Adhemerval Zanella via Libc-alpha
2020-05-21 13:14     ` Florian Weimer via Libc-alpha
2020-05-21 14:32       ` Adhemerval Zanella via Libc-alpha
2020-06-03 15:48         ` Florian Weimer via Libc-alpha
2020-06-03 17:52           ` Adhemerval Zanella via Libc-alpha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d06x75d2.fsf@oldenburg2.str.redhat.com \
    --to=libc-alpha@sourceware.org \
    --cc=adhemerval.zanella@linaro.org \
    --cc=fweimer@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).