mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Jens Gustedt <jens.gustedt@inria.fr>
To: musl@lists.openwall.com
Subject: Re: Explaining cond var destroy [Re: [musl] C threads, v3.0]
Date: Wed, 13 Aug 2014 09:19:05 +0200	[thread overview]
Message-ID: <1407914345.4951.20.camel@eris.loria.fr> (raw)
In-Reply-To: <1407912210.4951.15.camel@eris.loria.fr>

[-- Attachment #1: Type: text/plain, Size: 2154 bytes --]

Am Mittwoch, den 13.08.2014, 08:43 +0200 schrieb Jens Gustedt:
> Am Dienstag, den 12.08.2014, 17:18 -0400 schrieb Rich Felker:
> > On Tue, Aug 12, 2014 at 09:09:21PM +0200, Jens Gustedt wrote:
> > > Rich,
> > > thanks a lot for looking into the code.
> > > 
> > > Am Dienstag, den 12.08.2014, 12:01 -0400 schrieb Rich Felker:
> > > > As far as I can tell, the only thing that's saving you from sending
> > > > futex wakes after free is that you're just using spinlocks.
> > > 
> > > No, I don't think so. These protect critical sections at the beginning
> > > of the cnd_t calls. The cnd_*wait calls hold the mutex at that time
> > > anyhow, so even if these would be implemented with mutexes (an extra
> > > one per cnd_t to protect the critical section) this wouldn't cause
> > > late wakes, I think.
> > 
> > I was talking about the unref-and-free code that's using spinlocks.
> 
> I don't understand, the unref-and-free code doesn't use spinlocks. It
> just uses an atomic_fetch_sub of 1 to determine if it is the last
> user. If it is not, it does nothing and returns.
> 
> (This is indeed supposing that atomic_fetch_sub is "lock-free" in the
> sense of the C standard, which basically means that it has no
> observable state from a signal handler. All architectures I know of
> have that property, but my knowledge is limited.)

ah, perhaps you meant that the unref-and-free was done while holding
the spinlock? Maybe in the version that I posted this was the
case. That was a bug that I have now corrected.

I also have added an initial check for the wakers to see if they have
anything to do before they go into the spinlock. This should basically
solve the herd-doing-wakeup problem, since as soon as all waiters are
considered to be unblocked, wakers will return immediately without
spinning.

Jens

-- 
:: INRIA Nancy Grand Est ::: AlGorille ::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2014-08-13  7:19 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-04  9:30 C threads, v3.0 Jens Gustedt
2014-08-04  9:33 ` Jens Gustedt
2014-08-04 14:50 ` Rich Felker
2014-08-04 16:48   ` Jens Gustedt
2014-08-04 17:06     ` Rich Felker
2014-08-04 22:16       ` Jens Gustedt
2014-08-04 22:36         ` Rich Felker
2014-08-06  3:52 ` Explaining cond var destroy [Re: [musl] C threads, v3.0] Rich Felker
2014-08-06  8:43   ` Jens Gustedt
2014-08-06  9:41     ` Jens Gustedt
2014-08-06 10:03       ` Rich Felker
2014-08-06 10:32         ` Jens Gustedt
2014-08-06 16:15           ` Rich Felker
2014-08-06 16:56             ` Jens Gustedt
2014-08-06 17:32               ` Rich Felker
2014-08-06 20:55                 ` Jens Gustedt
2014-08-06 22:04                   ` Rich Felker
2014-08-06 22:43                     ` Jens Gustedt
2014-08-06 23:15                       ` Rich Felker
2014-08-07  7:50                         ` Jens Gustedt
2014-08-07 10:52                           ` Szabolcs Nagy
2014-08-07 11:03                             ` Jens Gustedt
2014-08-07 16:13                           ` Rich Felker
2014-08-07 16:47                             ` Jens Gustedt
2014-08-07 17:25                               ` Rich Felker
2014-08-08  9:20                                 ` Jens Gustedt
2014-08-08 16:53                                   ` Rich Felker
2014-08-08 19:14                                   ` Rich Felker
2014-08-08 20:48                                     ` Rich Felker
2014-08-09  6:47                                       ` Jens Gustedt
2014-08-12  2:50                                         ` Rich Felker
2014-08-12  7:04                                           ` Jens Gustedt
2014-08-12 16:01                                             ` Rich Felker
2014-08-12 19:09                                               ` Jens Gustedt
2014-08-12 21:18                                                 ` Rich Felker
2014-08-13  6:43                                                   ` Jens Gustedt
2014-08-13  7:19                                                     ` Jens Gustedt [this message]
2014-08-06  9:50     ` Rich Felker

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=1407914345.4951.20.camel@eris.loria.fr \
    --to=jens.gustedt@inria.fr \
    --cc=musl@lists.openwall.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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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).