This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] mutex destruction (#13690): problem description and workarounds

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

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:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]