This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] mutex destruction (#13690): problem description and workarounds
- From: Torvald Riegel <triegel at redhat dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Thu, 04 Dec 2014 15:29:18 +0100
- Subject: Re: [RFC] mutex destruction (#13690): problem description and workarounds
- Authentication-results: sourceware.org; auth=none
- References: <1396621230 dot 10643 dot 7191 dot camel at triegel dot csb> <20141201153802 dot GV29621 at brightrain dot aerifal dot cx> <1417452125 dot 1771 dot 503 dot camel at triegel dot csb> <20141201170542 dot GY29621 at brightrain dot aerifal dot cx> <1417467150 dot 1771 dot 581 dot camel at triegel dot csb> <20141201212223 dot GZ29621 at brightrain dot aerifal dot cx> <1417553118 dot 3930 dot 14 dot camel at triegel dot csb> <20141202210316 dot GI29621 at brightrain dot aerifal dot cx>
On Tue, 2014-12-02 at 16:03 -0500, Rich Felker wrote:
> On Tue, Dec 02, 2014 at 09:45:18PM +0100, Torvald Riegel wrote:
> > The signal man pages list sem_wait as having to return EINTR if
> > interrupted, but what's the point?
>
> This applies to all uses of interrupting signal handlers, which is why
> I personally think they should be deprecated. However, you can work
> around the issue by repeating the signal with exponential backoff
> until the thread sending the signal can determine that the target
> thread has acted upon the interruption.
This does make assumptions about the implementation. For example, it
makes an assumption that the scheduler will schedule the sem_wait
eventually, despite the interruptions by the signal. It relies on
progress guarantees POSIX doesn't make to my knowledge.
I won't argue that this is a workaround when making certain assumptions
about the scheduler. And it's something people do when emulating
lock-freedom with actually obstruction-free synchronization. But this
is for experts.
IMO, we should discourage such assumptions, because they don't help
anybody. They don't make things easier to understand for programmers,
given that the real solution -- have the signal handler perform a
sem_post -- is relatively easy to understand and remember, and can do
without a loop that gives you statistical guarantees eventually, maybe.
They don't help implementations because then they don't get the
implementation freedom they had with proper synchronization and the real
solution (for example, they now *have* to block, and can't just
spin-wait).
To be clear: I agree that this is not yet based on making assumptions
about timing, which we should never support or make promises about ever.
Nonetheless, really understanding under which conditions this *has* to
work (and, thus, would be reliable under) is nontrivial. Doing it right
requires the standards to specify progress guarantees, which isn't
simple either. I have a proposal about that in ISO C++ SG1:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4156.pdf