mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <>
To: William Tang <>
Subject: Re: [musl] Spurious wake up in musl
Date: Sat, 2 Jul 2022 13:56:02 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sun, Jul 03, 2022 at 12:38:05AM +0800, William Tang wrote:
> Hi,
> According to the about page, the spurious wake up should not be possible:

That is not a correct reading. Spurious wakes are always possible.

> musl was the first Linux libc to have ..., the first to have condvars
> where newly-arrived waiters can't steal wake events from previous
> waiters
> However, when I use the following code to test spurious wake up:
> [...]
> And compile with command "musl-gcc -static main.c", it outputs:
> [main] Started working threads: 0x7efc7f212f38, 0x7efc7f1eff38
> [worker 0x7efc7f212f38] No more work need to be done!
> [worker 0x7efc7f1eff38] No more work need to be done!
> [worker 0x7efc7f1eff38] No more work need to be done!
> [worker 0x7efc7f1eff38] No more work need to be done!
> [worker 0x7efc7f212f38] Spurious wakeup occurred! Counter is 0!

These aren't contradictory. The guarantee is that wakes won't be
missed due to a newly-arriving waiter stealing one that should have
been seen by an already-present waiter. You seem to be reading that in
a sort of converse-direction as implying a waiter won't wake
spuriously -- maybe assuming a spurious wake would be stealing the
wake from another waiter, but that's not what's happening. Spuriou
wakes are an inherent part of using condvars, and any logic that
depends on them not happening is missing the point of how condvars
work and how they're supposed to be used.


      reply	other threads:[~2022-07-02 17:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-02 16:38 William Tang
2022-07-02 17:56 ` Rich Felker [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:

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

  git send-email \ \ \ \ \

* 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.
Code repositories for project(s) associated with this public inbox

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 NNTP newsgroup(s).