From: Thomas Rodgers <trodgers@redhat.com>
To: Jonathan Wakely <jwakely@redhat.com>
Cc: "Alessio G. B." <alessiogiovanni.baroni@gmail.com>,
libstdc++@gcc.gnu.org
Subject: Re: [PATCH] libstdc++: Implementation of class strand
Date: Mon, 10 Apr 2023 12:42:28 -0700 [thread overview]
Message-ID: <CAMmuTO8eA=ttUqfqB707W=5cb5dM-Niho3W0SToPNw6rYqSOJw@mail.gmail.com> (raw)
In-Reply-To: <CACb0b4=w_bhBabiF9QW_26sM_hj1Y6JLv7f3eShNvzAk5zuPQg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1788 bytes --]
IIRC, the Asio implementation checks to see if the current thread already
holds a lock, and if so, adopts the current lock and enqueues any child
tasks that are created and processes them after the user-provided function
returns, to avoid deadlock in the case that Jonathan outlines here.
On Wed, Mar 22, 2023 at 7:32 AM Jonathan Wakely via Libstdc++ <
libstdc++@gcc.gnu.org> wrote:
> On Tue, 23 Mar 2021 at 16:39, Jonathan Wakely <jwakely@redhat.com> wrote:
>
> > On 12/03/21 13:21 +0100, Alessio G. B. via Libstdc++ wrote:
> > >I expanded the implementation of the class strand of the Networking
> > >TS. Essentially, I
> > >implemented a token system so each thread knows when it can execute;
> > >the system is organized
> > >with 2 integers moving as a clock.
> >
> > Thanks for this patch. I'm not sure when I'll have time to review it,
> > and it might not be in time for the upcoming GCC 11 release. But the
> > patch has been received and will get reviewed, thanks.
> >
>
> Well I didn't think it would take me two years, sorry about that :-(
>
> + template<typename _Func>
> + void
> + invoke(unsigned int token, _Func&& __f)
> + {
> + std::unique_lock<std::mutex> __lock(_M_mutex);
> +
> + _M_cv.wait(__lock,
> + [token, next_token = _M_next_token]()
> + { return token == next_token; });
> +
> + try { decay_t<_Func>{std::forward<_Func>(__f)}(); }
> + catch(...) { }
> +
> + _M_next_token++;
> +
> + __lock.unlock();
> +
> + _M_cv.notify_all();
> + }
>
> It looks like this will run a user-provided function while holding the
> mutex lock. Won't that deadlock if the task added to the strand adds
> another task to the same strand? Is that forbidden by some requirement in
> the TS that I've forgotten?
>
>
prev parent reply other threads:[~2023-04-10 19:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-12 12:21 Alessio G. B.
2021-03-23 16:39 ` Jonathan Wakely
2023-03-22 14:31 ` Jonathan Wakely
2023-04-10 19:42 ` Thomas Rodgers [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMmuTO8eA=ttUqfqB707W=5cb5dM-Niho3W0SToPNw6rYqSOJw@mail.gmail.com' \
--to=trodgers@redhat.com \
--cc=alessiogiovanni.baroni@gmail.com \
--cc=jwakely@redhat.com \
--cc=libstdc++@gcc.gnu.org \
/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).