Re: [RFC][BZ #16159] Detecting that recursive mutex recursed.

[OndÅej BÃlka <neleai at seznam dot cz>]

On Wed, Nov 13, 2013 at 02:37:46PM -0500, Rich Felker wrote:
> On Wed, Nov 13, 2013 at 08:03:56PM +0100, OndÅej BÃlka wrote:
> > On Wed, Nov 13, 2013 at 01:12:57PM -0500, Rich Felker wrote:
> > > On Wed, Nov 13, 2013 at 02:46:08PM +0100, Ondrej Bilka wrote:
> 
> > Alternative solution that I wanted to avoid is to use additional
> > thread-local variable to detect signals. A count would be maintained by
> > atomic increment/decrement.
> > 
> > Do you know how to generate cmpxchgb instruction without lock prefix as
> > there is no need of interthread synchronization?
> 
> Why do you need any atomicity or asm? In principle, read, modify,
> write is perfectly valid for this usage as long as the write is atomic
> (e.g. not using 2 16-bit writes to implement a 32-bit write). If
> you're not happy assumin 32-bit writes are atomic, then yes, a little
> more work would be required.
>
You cannot do that as you are at mercy of compiler. With volatile
variable gcc will not use read-modify-write. Without that gcc in
int x = 0;
int main(){
   int z=1;
   x++;
   if (x<3)
    z=0;

   x--;
 return z;
}
happily optimizes x++ and x-- away.

 
> But I'd be more concerned about the cost of TLS access. Unfortunately
> this also applies with recursive mutexes, since they need TLS access
> to get their own thread id and record an owner.

You use TLS because it is faster than atomic instructions.

> On some archs (older
> MIPS where the instruction to get the thread pointer traps into
> kernelspace, and probably some relevant ARM variants) reading the
> thread pointer can be expensive, and I question whether this expense
> can be justified in malloc. I'd rather just abandon aims to make
> malloc AS-safe and focus on its performance, and have code that needs
> malloc-like functionality with AS-safety use another interface.
>
Improving malloc performance means using TLS. Currently malloc is
limited in small sizes by slowness of atomic instructions. 
> 
> 
> P.S. glibc still officially supports user replacement of malloc, so
> nothing in libc is justified in assuming properties of its own malloc
> implementation like AS-safety.

In theory yes, in practice we want to debug these issues, not cause
incomprehensible corruption long after signal was handled.