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: My current understanding of cond var access restrictions
Date: Thu, 14 Aug 2014 22:47:24 +0200	[thread overview]
Message-ID: <1408049244.4951.132.camel@eris.loria.fr> (raw)
In-Reply-To: <20140814182314.GI12888@brightrain.aerifal.cx>

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

Am Donnerstag, den 14.08.2014, 14:23 -0400 schrieb Rich Felker:
> On Thu, Aug 14, 2014 at 08:12:46PM +0200, Jens Gustedt wrote:
> > I don't think they are too bad, actually. They help to distinguish two
> > phases for a waiting thread. In the first, he has released the mutex
> > and no signal or broadcast has been issued. A thread should never
> > attempt to relock the mutex and/or return to user space during that
> > phase.
> > 
> > And then the second phase after such a signal or broadcast, where any
> > wakeup could be legitimate and in the worst case just be spurious.
> 
> Yes. Really the only reason I dislike sequence numbers is the
> theoretical possibility of wrapping after 2<<32 signals. This would
> require extreme scheduling delays to realize without a signal handler
> intentionally preventing the waiter from making forward progress, so
> it's unlikely to impact anything, but it still seems wrong.

Wrapping alone doesn't matter, waiters don't have just to do an
equality test on the sequence counter. So with the traditional int
(and supposing that there is no UB because of the overflow) even
negative values may occur with no harm. The thing that would do harm
would be the waiter that is woken up *exactly* 2<<32 sequence points
later and concludes that the world hasn't changed. Really hard to
generate a test program for that bug :)

But why not give it a 64 bit integer then? It seems to me that
__u.i[9] is unused, so with a shift of the whole crowd _c_seq could
get two slots.

Ah, and for the records for the discussion on mutex we had before,
pthread_mutex_t also seems to have an empty slot, namely __u.__i[3],
no? Or was it intended that _c_count be in that, and using __u.i[5]
for it is a typo?

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-14 20:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-13 21:23 Rich Felker
2014-08-13 23:20 ` Jens Gustedt
2014-08-14  2:19   ` Rich Felker
2014-08-14  7:41     ` Jens Gustedt
2014-08-14  6:10   ` Rich Felker
2014-08-14  8:00     ` Jens Gustedt
2014-08-14 14:41       ` Rich Felker
2014-08-14 15:36         ` Rich Felker
2014-08-14 16:27         ` Jens Gustedt
2014-08-14 16:58           ` Rich Felker
2014-08-14 18:12             ` Jens Gustedt
2014-08-14 18:23               ` Rich Felker
2014-08-14 20:47                 ` Jens Gustedt [this message]
2014-08-14 22:22                   ` 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=1408049244.4951.132.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).